[HACKERS] Re: [BUGS] BUG #8128: pg_dump (>= 9.1) failed while dumping a scheme named "old" from PostgreSQL 8.4
On Wed, May 1, 2013 at 6:38 PM, Tom Lane wrote: > This is complete nonsense, because David's argument is pretty clearly not nonsense. I think they're valid well reasoned arguments. It's just that the evidence is mixed and on balance leans towards not unnecessarily reserving keywords. Fwiw we've done it at least once in the past (RECURSIVE maybe?) and I recall it didn't actually go so well in the end. Either it took multiple revisions before the preemptively reserved word was useful or it didn't end up needing to be reserved as we expected, I forget. If the spec were more static and we had a real expectation of reaching completeness on some fixed timetable then I think David would be pretty solidly correct. I don't think anyone would stand for a C compiler that let users use reserved words in some contexts as identifiers without a warning by default. It would be doing a disservice to users who would one day try to compile their code on another compiler or be surprised that their identifiers couldn't be used in other contexts. If we could do a competent job of it it would be nice to support a mode that warned users when they used non-standard syntaxes. But we can't. If we warned about keywords that are reserved in the standard but not known by postgres that would be hardly scratching the surface. It would do nothing but give users a false sense of security and it would be pretty awkward to implement even that, nevermind something that actually reached a useful level of completeness. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [BUGS] BUG #8128: pg_dump (>= 9.1) failed while dumping a scheme named "old" from PostgreSQL 8.4
David Fetter writes: > On Wed, May 01, 2013 at 11:12:28AM -0400, Tom Lane wrote: >> David Fetter 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [BUGS] BUG #8128: pg_dump (>= 9.1) failed while dumping a scheme named "old" from PostgreSQL 8.4
On 05/01/2013 06:14 PM, David Fetter wrote: > On Wed, May 01, 2013 at 11:12:28AM -0400, Tom Lane wrote: >> David Fetter 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. > > 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. past history has shown that this is relatively rare and almost always it was possible to find a way around - not sure why we need to panic in advance? > > If you want to have a discussion about the timing, that is a perfectly > reasonable discussion to have. Peremptorily saying, "don't and won't" > is not a great way to operate, however tempting it may be for you. > > 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. as per the discussion on IRC - this would break applications left and right for no real reason and no good, and I don't think hypothetical features that have not even fully discused warrant anything like that. Also this would be an uphill battle for no good (ie every few years when a new spec comes out we break apps for a feature we might geht 10 years later?) > > I'd suggest doing this over about 3 releases in the sense of warning > people at the appropriate juncture--I'm guessing at least CREATE, > ALTER, pg_dump(all) and pg_upgrade would be involved. Three releases > is just a suggestion intended to start a discussion. > >> 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. why is breaking random applications or making it harder for people to migrate from other databases without any reason a good thing? Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [BUGS] BUG #8128: pg_dump (>= 9.1) failed while dumping a scheme named "old" from PostgreSQL 8.4
On Wed, May 01, 2013 at 11:12:28AM -0400, Tom Lane wrote: > David Fetter 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. 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. If you want to have a discussion about the timing, that is a perfectly reasonable discussion to have. Peremptorily saying, "don't and won't" is not a great way to operate, however tempting it may be for you. 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. I'd suggest doing this over about 3 releases in the sense of warning people at the appropriate juncture--I'm guessing at least CREATE, ALTER, pg_dump(all) and pg_upgrade would be involved. Three releases is just a suggestion intended to start a discussion. > 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. Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [BUGS] BUG #8128: pg_dump (>= 9.1) failed while dumping a scheme named "old" from PostgreSQL 8.4
David Fetter 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. There are very many other keywords that are less reserved in Postgres than in the spec; this is a good thing. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [BUGS] BUG #8128: pg_dump (>= 9.1) failed while dumping a scheme named "old" from PostgreSQL 8.4
On 05/01/2013 04:26 PM, David Fetter wrote: > On Tue, Apr 30, 2013 at 07:53:27PM -0400, Tom Lane wrote: >> adrian.vondendrie...@credativ.de writes: >>> [ recent pg_dump fails against an 8.4 server if "old" is used as a >>> name ] >> >> Yeah. The reason for this is that "old" was considered a reserved >> word in 8.4 and before, but since 9.0 it is not reserved (indeed it >> isn't a keyword at all anymore), so 9.0 and later pg_dump don't >> think they need to quote it in commands. > > 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. erm? I don't really see why we have any need to reserve something _on purpose_ when there is no technical reason to do so... > > Sadly, this will cause problems for people who have tables with those > names, but we've introduced incompatibilities (in 8.3, e.g.) that hit > a much bigger part of our user base much harder than this. When we do > re-reserve, we'll need to come up with a migration path. so why again do we want to create an(other) incompatibility hazard? Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [BUGS] BUG #8128: pg_dump (>= 9.1) failed while dumping a scheme named "old" from PostgreSQL 8.4
On Tue, Apr 30, 2013 at 07:53:27PM -0400, Tom Lane wrote: > adrian.vondendrie...@credativ.de writes: > > [ recent pg_dump fails against an 8.4 server if "old" is used as a > > name ] > > Yeah. The reason for this is that "old" was considered a reserved > word in 8.4 and before, but since 9.0 it is not reserved (indeed it > isn't a keyword at all anymore), so 9.0 and later pg_dump don't > think they need to quote it in commands. 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. Sadly, this will cause problems for people who have tables with those names, but we've introduced incompatibilities (in 8.3, e.g.) that hit a much bigger part of our user base much harder than this. When we do re-reserve, we'll need to come up with a migration path. Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers