Robert Haas <robertmh...@gmail.com> writes: > If it were a question of writing this code once and being done with > it, that would be unobjectionable in my view. But it isn't. > Practically every change to gram.y is going to require a corresponding > change to this stuff. As far as I can see, nobody except me has > commented on the burden that places on everyone who may wish to add > syntax support for a new construct in the future, which might mean > that I'm worrying about something that isn't worth worrying about, but > what I think is more likely is that nobody's worrying about it right > now because they haven't had to do it yet.
I haven't been paying much attention to this thread, but I concur with Robert that adding yet another set of overhead requirements to any addition of new SQL is not a good thing. > Just to illustrate the point, consider the CREATE TABLE name OF type > syntax that Peter added a few years ago. That patch > (e7b3349a8ad7afaad565c573fbd65fb46af6abbe) had the following impact on > gram.y: This analysis is kind of cheating, because adding new syntax hasn't been only a matter of touching gram.y for a very long time. You invariably have to touch pg_dump, and you have to touch ruleutils.c unless it's strictly a DDL-command change. But people are used to those, and the value of keeping pg_dump working is clear to everybody. Adding a similar level of burden to support a feature with a narrow use-case seems like a nonstarter from here. ESPECIALLY if we also have to manually add regression test cases because there's no easy way to test it directly. 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