Re: [BUGS] BUG #8128: pg_dump (>= 9.1) failed while dumping a scheme named "old" from PostgreSQL 8.4
От | Greg Stark |
---|---|
Тема | Re: [BUGS] BUG #8128: pg_dump (>= 9.1) failed while dumping a scheme named "old" from PostgreSQL 8.4 |
Дата | |
Msg-id | CAM-w4HOd3N_ozMygs==Lm5+hU8yQKKaYutGjiNp6z2hAzDrSTA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: [BUGS] BUG #8128: pg_dump (>= 9.1) failed while dumping a scheme named "old" from PostgreSQL 8.4 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Wed, May 1, 2013 at 6:38 PM, Tom Lane <tgl@sss.pgh.pa.us> 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
В списке pgsql-hackers по дате отправления: