So I think we're agreed on adding a variable_conflict GUC for plpgsql.
The straight-and-narrow way to do it would be to make this a custom
GUC that's defined only when plpgsql is dynamically loaded into the
backend. However that implies a lot of notational overhead, notably
having to put plpgsql into custom_variable_classes if you want to set
the variable in postgresql.conf. Maybe that's okay, particularly if
you are of the opinion that most people will leave it at default.
But it could also be argued that plpgsql is so widely used that we
should bend the rules for it, and make this a built-in GUC that just
happens to only be consulted by plpgsql.
I'm leaning to the custom GUC approach because it seems a little
cleaner from a code point of view, but I wanted to see if anyone
wishes to argue for the other way.
One reason to argue for the other way is that maybe it wouldn't only
be consulted by plpgsql. In particular I can easily imagine SQL
functions having the same issue as soon as someone gets around to
letting them use names for their parameters.
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
