Peter Eisentraut <[EMAIL PROTECTED]> 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. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly