Re: Need SQL Reserved words list for DB/2, Ingress, MS-Access. Summary will be created.

I disagree that adding EXTENSION_ before EVERY extension is a good thing. I suggest you try writing your typical Sybase or Informix or DB2 or Oracle SQL stmt that way and see how readable it ends up being. I would suggest that more and more SQL will be generated by browsers and GUI tools etc. and that quoting makes like simple for those tools. If you care whether or not you're using an extension you can always use the flagger which is a required part of an ANSI implementation. Also, most users don't make enough use of the renaming features of SQL. I suggest always using aliases for table names for examle

SELECT ... FROM "BIG_BAD_TABLE_NAME" BB
WHERE BB."SAL" > 100 as a convenience/doc aid as the SQL stmt gets larger and more complex. Table names aren't always the most meaningful ways to name data in a query!  

In article <817478610snz_at_knosof.co.uk>, derek_at_knosof.co.uk wrote:

> All,
>
> In article <kbradley-2211951430410001_at_kbradley-mac.us.oracle.com>
> kbradley_at_us.oracle.com "Kirk Bradley" writes:
> >
> >
> > In fact, there should NEVER be a need to know the reserved word list if
> > the SQL system is ANSI compatible. ANSI says that they own all future
> > words (not in those words of course) and that the only way for users
> > to guarantee ANSI compatible SQL forever is to enclose their object names
> > in double quotes. So:
> >
> > SELECT "SELECT" FROM "FROM" WHERE "WHERE" = "OVERTHERE"
> >
> > will always work properly. Some non-ANSI compliant systems will have
> > problems cause they use single and double quotes interchangeably. They
> > will have to be fixed sometime.
> >
> > In article <DIC40u.Kz_at_actcom.co.il>, astea_at_actcom.co.il (Astea
> > International) wrote:
> >
>
> Such a statement obviously shows scant disregard for the users
> convenience. The main purpose of allowing identifiers enclosed in
> double quotes is to to provide the ability to use 'strange' characters
> within identifier names.
>
> Having the SQL committee tell users that any word may become reserved
> on a fucture revision of a standard is not being very helpful. I would hope
> that the committee considers the impact of reserving a new word on
> existing code very carefully indeed.
>
> > >
> > > If you want to make your client-server application
> > > compatible to other DBMSs,
> > > avoiding using those reserved words is a good practice
> > > and will save a huge amout of work later.
> > >
> > > *******************************************************
> > > *Astea Israel - Tefen Labs *
> > > * Email: astea_at_actcom.co.il *
> > > * Phone: (972) 4 - 987 2519 *
> > > * Fax: (972) 4 - 987 2031 *
>
> Of course the real problem is not new reserved words added by the SQL
> committee, but reserved words added by vendors.
>
> Perhaps the committee could help solve this problem by requiring that
> all vendor reserved words start with the letters EXTENSION_. This seems
> to be a much more practical alternative than requiring all user identifiers
> be enclosed in double quotes. It also has the added advantage of
> highlighting the exactly which extensions were being used.
>
> derek
Received on Mon Nov 27 1995 - 00:00:00 CET