Re: Call for objections: revision of keyword classification

How do some of the other RDBMSs handle this? I've gotten into the habit
awhile ago of not using 'field types' as 'field names' that not using
something like 'timestamp' as a field name comes naturally ... ignoring
going from old-PgSQL to new-PgSQL ... what about PgSQL->Oracle? I
personally like it when I see apps out there that strive to work with
different DBs, I'd hate to see it be us that makes life more difficult for
ppl to make choices because we 'softened restrictions' on reserved words,
allowing someone to create an app that works great under us, but is now a
headache to change to someone else's RDBMSs as a result ...

... if that makes any sense?

On Thu, 8 Nov 2001, Tom Lane wrote:

> Thomas Lockhart <lockhart(at)fourpalms(dot)org> writes:
> > The only reservation I have (pun not *really* intended ;) is that the
> > SQL9x reserved words may continue to impact us into the future, so
> > freeing them up now may just postpone the pain until later. That
> > probably is not a good enough argument (*I* don't even like it) but any
> > extra flexibility we put in now is not guaranteed to last forever...
>
> Of course not, but we might as well do what we can while we can.
>
> One positive point is that (I think) we are pretty close to SQL9x now
> on datatype declaration syntax, so if we can make these words unreserved
> or less-reserved today, it's not unreasonable to think they might be
> able to stay that way indefinitely.
>
> > In either case, having reserved words which are also reserved in the SQL
> > standard will not keep folks from using PostgreSQL, and allowing them
> > will not be a difference maker in adoption either imho.
>
> No, it won't. I'm mainly doing this to try to minimize the pain of
> people porting forward from previous Postgres releases, in which
> (some of) these words weren't reserved. That seems a worthwhile
> goal to me, even if in the long run they end up absorbing the pain
> anyway. Certain pain now vs maybe-or-maybe-not pain later is an
> easy tradeoff ;-)
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>