David Fetter <david@fetter.org> writes:
> On Wed, May 01, 2013 at 11:12:28AM -0400, Tom Lane wrote:
>> David Fetter <david@fetter.org> writes:
>>> According to SQL:2003 and SQL:2008 (and the draft standard, if
>>> that matters) in section 5.2 of Foundation, both NEW and OLD are
>>> reserved words, so we're going to need to re-reserve them to
>>> comply.
>> We don't and won't.
> Not so fast or so definite, if you please.
Yeah, I should have said "we don't and won't reserve keywords merely
because the SQL spec lists them as reserved".
> I've got a GSoC project in that implements things with both of these
> keywords, and doubtless others will use other keywords either this
> coming (9.4) cycle or in a later one.
That's fine. When somebody submits a feature patch that requires
reserving a formerly-not-reserved word, we'll have a discussion about
whether the feature is worth the risk of breaking applications and
whether there isn't a way to avoid fully reserving the word. Frequently
it's possible to avoid that with some grammar rearrangement. We've
sweated blood before to avoid reserving common words, and I'm sure we
will continue that approach.
> There is a case to be made, and I'm making it here, for pre-reserving
> all the keywords and erroring out with "Feature not implemented" for
> those not yet implemented. This would keep us, and more importantly
> our user base, from wondering when the next random change to the SQL
> language would affect them.
This is complete nonsense, because
(a) every time the SQL committee comes out with a new revision, there
are new reserved words, many of which are for features that Postgres
may not have for years, if ever. You are simply proposing that we break
applications on the committee's timetable rather than our own, and
perhaps break them needlessly.
(b) it's often possible to implement the spec syntax without reserving
the word, or without reserving it completely. We always do this if it's
feasible. For example, there are a lot of functions whose names are
reserved words according to the spec, but Postgres just thinks they're
ordinary functions. It would serve no purpose to make them really
reserved; in fact, it would make life harder for us as well as our
users. Even where it does make it harder for us, we've always judged
that not breaking existing applications was worth a fair amount of pain.
>> There are very many other keywords that are less reserved in
>> Postgres than in the spec; this is a good thing.
> How is it a good thing? Help me understand.
Because it avoids breaking applications that had been using those
words as object names.
regards, tom lane
