Re: Operators and schemas

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Tuesday, April 16, 2002 3:58 PM
To: Peter Eisentraut
Cc: Fernando Nasser; pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Operators and schemas

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I can hardly believe that we want to implement this just to be able to
> check off a few boxes on the SQL-compliance test. Once you have the
> ability to use a fixed list of statements in this context it should be
> easy to allow a more or less arbitrary list. Especially if they all
start
> with the same key word it should be possible to parse this.

It's not the "start" part that creates the problem, so much as the "end"
part. What we found was that we were having to reserve secondary
keywords. CREATE is now fully reserved, which it was not in 7.2,
and that alone doesn't bother me. But AUTHORIZATION and GRANT are
more reserved than they were before, too, and it'll get worse the
more statements we insist on accepting inside CREATE SCHEMA.

AFAICS, embedding statements inside CREATE SCHEMA adds absolutely zero
functionality; you can just as easily execute them separately. Do we
really want to push a bunch more keywords into full-reserved status
(and doubtless break some existing table definitions thereby) just
to check off a box that isn't even in the SQL compliance test?

To the extent that we can allow stuff in CREATE SCHEMA without adding
more reserved words, it's fine with me. But I question having to add
reserved words to do it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
If the alternative is to make a permanent fork in the road that leads
away from ANSI compiliance, then it is a very, very bad decision not
to put in the new keywords. Every week that passes by will make
correcting the problem become more and more expensive.

IMO-YMMV.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<