I wrote:
> ... It strikes me though that if
> we're going to invent an opt_if_not_exists production in the grammar,
> there are a lot of other places where it should be used too, for
> consistency if nothing else.
BTW, I tried to do this and realized that it doesn't work, because IF
is not a reserved word. The only way that opt_if_not_exists isn't
ambiguous is if it must appear before something that's not an
identifier, which is to say it works in ALTER TYPE ADD VALUE ... Sconst
and nowhere else. Otherwise you have to spell it out with duplicate
productions so that bison doesn't have to make a shift/reduce decision
till it's seen the whole phrase.
If we're ever forced to make IF reserved for other reasons, we could
clean up a lot of both IF EXISTS and IF NOT EXISTS productions.
There are other ways we could refactor the productions involved to
reduce duplication; for instance I think that we could make it work for
CREATE TABLE IF NOT EXISTS by defining a nonterminal that expands to
either "qualified_name" or "IF NOT EXISTS qualified_name". But that
seems ugly enough to not be much of an improvement, not least because
the nonterminal would need to return two separate pieces of info,
and that's not terribly easy in bison.
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
