On mån, 2010-01-25 at 20:26 -0500, Tom Lane wrote:
> Simon Riggs 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,
On mån, 2010-01-25 at 20:26 -0500, Tom Lane wrote:
> Simon Riggs 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,
On Mon, Jan 25, 2010 at 08:26:14PM -0500, Tom Lane wrote:
> Simon Riggs 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 PL
On Mon, 2010-01-25 at 20:26 -0500, Tom Lane wrote:
> 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.)
+1
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pg
Simon Riggs 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 interpr
--On 25. Januar 2010 09:30:56 -0500 Robert Haas
wrote:
This will turn into
another setting like search_path and standard_conforming_strings that
can break working code if the actual value doesn't match the
anticipated value. I can't figure out why someone would want to use
this even if we
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.
--
Simon Ri
On Mon, Jan 25, 2010 at 3:55 AM, Simon Riggs wrote:
> On Mon, 2010-01-25 at 09:08 +0200, Peter Eisentraut wrote:
>> On sön, 2010-01-24 at 20:32 +, Simon Riggs wrote:
>> > Why do we have a parameter called "default_do_language" when we don't
>> > have a parameter called "default_language"?
>>
>
On Mon, 2010-01-25 at 09:08 +0200, Peter Eisentraut wrote:
> On sön, 2010-01-24 at 20:32 +, Simon Riggs wrote:
> > Why do we have a parameter called "default_do_language" when we don't
> > have a parameter called "default_language"?
>
> According to the SQL standard, the default language for C
2010/1/25 Peter Eisentraut :
> On mån, 2010-01-25 at 08:09 +0100, Pavel Stehule wrote:
>> 2010/1/25 Peter Eisentraut :
>> > On sön, 2010-01-24 at 20:32 +, Simon Riggs wrote:
>> >> Why do we have a parameter called "default_do_language" when we don't
>> >> have a parameter called "default_langua
On mån, 2010-01-25 at 08:09 +0100, Pavel Stehule wrote:
> 2010/1/25 Peter Eisentraut :
> > On sön, 2010-01-24 at 20:32 +, Simon Riggs wrote:
> >> Why do we have a parameter called "default_do_language" when we don't
> >> have a parameter called "default_language"?
> >
> > According to the SQL s
2010/1/25 Peter Eisentraut :
> On sön, 2010-01-24 at 20:32 +, Simon Riggs wrote:
>> Why do we have a parameter called "default_do_language" when we don't
>> have a parameter called "default_language"?
>
> According to the SQL standard, the default language for CREATE FUNCTION
> is SQL. Should
On sön, 2010-01-24 at 20:32 +, Simon Riggs wrote:
> Why do we have a parameter called "default_do_language" when we don't
> have a parameter called "default_language"?
According to the SQL standard, the default language for CREATE FUNCTION
is SQL. Should we implement that?
--
Sent via pgsq
On Sun, 2010-01-24 at 23:59 +, Greg Stark wrote:
> On Sun, Jan 24, 2010 at 11:18 PM, Simon Riggs wrote:
> > I would prefer having the option, but removing it completely does at
> > least solve the bizarre inconsistency I've highlighted.
> >
>
> I don't see it as much of an inconsistency. The
Greg Stark wrote:
On Sun, Jan 24, 2010 at 11:18 PM, Simon Riggs wrote:
I would prefer having the option, but removing it completely does at
least solve the bizarre inconsistency I've highlighted.
I don't see it as much of an inconsistency. The whole point of DO is
to be convenient,
On Sun, Jan 24, 2010 at 11:18 PM, Simon Riggs wrote:
> I would prefer having the option, but removing it completely does at
> least solve the bizarre inconsistency I've highlighted.
>
I don't see it as much of an inconsistency. The whole point of DO is
to be convenient, whereas CREATE FUNCTION is
On Sun, 2010-01-24 at 17:04 -0500, Tom Lane wrote:
> > 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
On Jan 24, 2010, at 2:04 PM, Tom Lane wrote:
> 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
Jeff Davis 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
constr
Simon Riggs writes:
> Please can we have "default_language"?
That sounds like something I could want to use someday.
> Or "language_path" so we can tell
> CREATE FUNCTION to try the languages in order? Or better still, try all
> the installed languages that the user has rights to in alphabetic
On Sun, 2010-01-24 at 20:32 +, Simon Riggs wrote:
> Or "language_path" so we can tell
> CREATE FUNCTION to try the languages in order? Or better still, try all
> the installed languages that the user has rights to in alphabetic
> order?
What do you mean "try"? It seems a little dangerous to j
Why do we have a parameter called "default_do_language" when we don't
have a parameter called "default_language"?
This is remarkably inconsistent. Why the difference? 5 years from now,
whatever reason we had will seem just strange.
Please can we have "default_language"? Or "language_path" so we
22 matches
Mail list logo
