On 21 May 2013 09:07, Matt Olson wrote:
I think a DCR request is the way to go.
No harm in asking. Personally I would not wait for the DB2 for i SQL
to add that specific feature, in order to effect a correction that is
required more presently... as that could be a long wait :-) I would
instead do what is necessary with what is available presently, to get
done what I needed done... presently.
There is no way it needs to be nearly this complicated.
Whatever enhancement *I* desire should exist, is a trivial matter to
be provided to me, whenever *someone else* has to do the work to make
that feature happen ;-)
The combined requests RENAME and CREATE VIEW to logically effect the
renamed column is fairly trivial. And hardly complicated, especially if
there is a GUI or script generator used to assist in the creation. The
typical production application will never have any knowledge of nor any
requirement to know, that the name reference is to a VIEW versus a
TABLE; i.e. only maintenance requests such as those which might ALTER or
GRANT would care about TABLE vs VIEW, but a requester of DML remains
oblivious and unconcerned. This is effectively the same /resolution/
anyone would likely have used for RLA as well; i.e. CRTLF to make a new
RcdFmt, then the applications use the LF instead of the PF.
And FWIW, a SQL stored procedure could implement the required
scripted actions fairly easily, for the more literal effect of a renamed
column within a TABLE, but of course with the consequences of the DROP
COLUMN. For example, the request to CALL RENAME_COLUMN
('Schema_Name.Table_Name', 'Old_Column_Name', 'New_Column_Name') could
perform the required ALTER activity for a particular column of a TABLE,
having defined the routine RENAME_COLUMN to use dynamically generated
requests from information in the catalogs [or from DSPFFD or similar].
They can look at how MS SQL Server does it as a
good model to base it off of.
I do not think they will need to see anything else to determine how
to implement such a feature on the object-based IBM i OS that must also
consider effects for its integrated /database file/ objects that contain
the definitional attributes which are merely reflected in the catalogs.
The DB2 for i SQL will implement what is in the [ANS] standards for
the language to accomplish an effective RENAME COLUMN. Other databases
operating within a separate ecosystem to define their SQL /database/ via
textual definitions, would not do well to serve as a model for the
fairly unique DB2 for i using the integrated object-based model.
Or just execute the alter column syntax that was previously
referenced which exists in LUW version of DB2 but seems to be missing
from IBM i's DB2 flavor (these two development teams really need to
grab a cup of coffee and talk to each other once in a while).
See here:
http://pic.dhe.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=%2Fcom.ibm.db2.luw.admin.dbobj.doc%2Fdoc%2Ft0020130.html
If the feature is part of the SQL standards, or even just as pressure
to be more compatible with what is provided by the DB2LUW SQL, then the
feature [even if not all the same capabilities] will likely come to the
DB2 for i SQL; eventually, DCR or not. A DCR however, will show there
is interest from actual customer(s).
IMO the ability to rename a column is rather worthless, as compared
to whatever else the DB2 for i and its SQL could provide. I would much
rather have a stored procedure to effect *CALLLVL scoped overrides, the
double quote enabled as a literal\constant delimiter, and a slew of
other things. I perceive little value from having a feature to help me
recover from my own poor planning in the design and\or implementation of
my DDL.
midrange.com
