Re: [HACKERS] default_language

2010-01-25 Thread Simon Riggs
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 CREATE

Re: [HACKERS] default_language

2010-01-25 Thread Robert Haas
On Mon, Jan 25, 2010 at 3:55 AM, Simon Riggs si...@2ndquadrant.com 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

Re: [HACKERS] default_language

2010-01-25 Thread Simon Riggs
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

Re: [HACKERS] default_language

2010-01-25 Thread Bernd Helmle
--On 25. Januar 2010 09:30:56 -0500 Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] default_language

2010-01-25 Thread Tom Lane
Simon Riggs si...@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

Re: [HACKERS] default_language

2010-01-25 Thread Jeff Davis
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

Re: [HACKERS] default_language

2010-01-25 Thread David Fetter
On Mon, Jan 25, 2010 at 08:26:14PM -0500, Tom Lane wrote: Simon Riggs si...@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

Re: [HACKERS] default_language

2010-01-25 Thread Peter Eisentraut
On mån, 2010-01-25 at 20:26 -0500, Tom Lane wrote: Simon Riggs si...@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

Re: [HACKERS] default_language

2010-01-25 Thread Peter Eisentraut
On mån, 2010-01-25 at 20:26 -0500, Tom Lane wrote: Simon Riggs si...@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

[HACKERS] default_language

2010-01-24 Thread Simon Riggs
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 can

Re: [HACKERS] default_language

2010-01-24 Thread Jeff Davis
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 just try

Re: [HACKERS] default_language

2010-01-24 Thread Dimitri Fontaine
Simon Riggs si...@2ndquadrant.com 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

Re: [HACKERS] default_language

2010-01-24 Thread Tom Lane
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

Re: [HACKERS] default_language

2010-01-24 Thread David E. Wheeler
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 a

Re: [HACKERS] default_language

2010-01-24 Thread Simon Riggs
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 wasn't

Re: [HACKERS] default_language

2010-01-24 Thread Greg Stark
On Sun, Jan 24, 2010 at 11:18 PM, Simon Riggs si...@2ndquadrant.com 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

Re: [HACKERS] default_language

2010-01-24 Thread Andrew Dunstan
Greg Stark wrote: On Sun, Jan 24, 2010 at 11:18 PM, Simon Riggs si...@2ndquadrant.com 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

Re: [HACKERS] default_language

2010-01-24 Thread Simon Riggs
On Sun, 2010-01-24 at 23:59 +, Greg Stark wrote: On Sun, Jan 24, 2010 at 11:18 PM, Simon Riggs si...@2ndquadrant.com 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

Re: [HACKERS] default_language

2010-01-24 Thread 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 we implement that? -- Sent via

Re: [HACKERS] default_language

2010-01-24 Thread Pavel Stehule
2010/1/25 Peter Eisentraut pete...@gmx.net: 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.  

Re: [HACKERS] default_language

2010-01-24 Thread Peter Eisentraut
On mån, 2010-01-25 at 08:09 +0100, Pavel Stehule wrote: 2010/1/25 Peter Eisentraut pete...@gmx.net: 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

Re: [HACKERS] default_language

2010-01-24 Thread Pavel Stehule
2010/1/25 Peter Eisentraut pete...@gmx.net: On mån, 2010-01-25 at 08:09 +0100, Pavel Stehule wrote: 2010/1/25 Peter Eisentraut pete...@gmx.net: 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