On mån, 2010-01-25 at 20:26 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > On Mon, 2010-01-25 at 09:30 -0500, Robert Haas wrote:
> >> +1 for removing default_do_language, too.
>
> > +1 for removing default_do_language OR adding default_language.
>
> > I prefer a hard-wired default of PLpgSQL, so a missing language
> > statement on a DO block is always interpreted the same.
>
> So it seems everyone is okay with the latter? (Remove
> default_do_language in place of a hard-wired default of "plpgsql",
> don't change CREATE FUNCTION's behavior.)
Another option, which would avoid the hardcoding, would be to add a
column to pg_language to indicate which is the default language. That
would be kind of like the way the default operator classes are handled:
There are valid reasons to change them on occasion, but you should
really know what you are doing.
Maybe that's not something we have to implement right now, but perhaps
let's keep it in mind.