Jeff Davis <pg...@j-davis.com> writes:
> I would actually lean the other way and say that we shouldn't be
> introducing behavior-changing GUCs (except for the special case of
> supporting legacy behavior, like standard_conforming_strings).
Yeah --- GUCs that affect semantics (as opposed to performance) of SQL
constructs have many downsides, as we have found out over the years.
I'm not seeing that this idea has enough usefulness to justify the
risks.
> If we have a default (for DO and CREATE FUNCTION), why not hard-wire the
> default to plpgsql?
I don't see any strong argument for having a default for CREATE
FUNCTION. The original argument for having a GUC for DO was that
plpgsql wasn't built in; now that it is, I think a case could
be made for dropping default_do_language in favor of a hardwired
default.
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
