Re: default_language

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: default_language
Date: 2010-01-26 06:40:04
Message-ID: 1264488004.14033.3.camel@fsopti579.F-Secure.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On mån, 2010-01-25 at 20:26 -0500, Tom Lane wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2010-01-26 06:59:35 Re: Review: listagg aggregate
Previous Message Peter Eisentraut 2010-01-26 06:35:27 Re: default_language