Обсуждение: default_language
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 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? (The latter behaviour would be backpatchable to allow code to be more portable across releases, but "backpatch" may be a Treadstone trigger word). -- Simon Riggs www.2ndQuadrant.com
On Sun, 2010-01-24 at 20:32 +0000, 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 to
compile until it doesn't throw an error.
Consider the following program:
len('aaaaaaaaaaaaaa')
Is that ruby or python? It's probably python, because python has a
built-in function "len". However, ruby doesn't know that the "len"
function doesn't exist until runtime -- so perhaps it's just a ruby
program that happens to throw a runtime error?
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). If we
have a default (for DO and CREATE FUNCTION), why not hard-wire the
default to plpgsql?
Regards,Jeff Davis
Simon Riggs <simon@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 in alphabetic > order? That sounds like something I will regret we have anyday. Like you make a typo on your plpgsql function so PostgreSQL will try to see how it fits as a plperl one ? No thanks. I guess I'm misunderstanding the behavior you have in mind. Regards, -- dim
Jeff Davis <pgsql@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
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 hardwired > default. +1 David
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 built in; now that it is, I think a case could > be made for dropping default_do_language in favor of a hardwired > default. I would prefer having the option, but removing it completely does at least solve the bizarre inconsistency I've highlighted. -- Simon Riggs www.2ndQuadrant.com
On Sun, Jan 24, 2010 at 11:18 PM, Simon Riggs <simon@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 CREATE FUNCTION is DDL for defining what your database looks like and it should be well defined in perpetuity. However it's also possible will write DO blocks into their application code in which case it might be preferable not to have a default_language GUC which would have to be set correctly for the code to work. -- greg
Greg Stark wrote: > On Sun, Jan 24, 2010 at 11:18 PM, Simon Riggs <simon@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 CREATE FUNCTION is DDL for defining what > your database looks like and it should be well defined in perpetuity. > > However it's also possible will write DO blocks into their application > code in which case it might be preferable not to have a > default_language GUC which would have to be set correctly for the code > to work. > Yeah, it's the possibility of scripts or functions with embedded DO statements that makes me think we'd be better off without a setting for this. cheers andrew
On Sun, 2010-01-24 at 23:59 +0000, Greg Stark wrote: > On Sun, Jan 24, 2010 at 11:18 PM, Simon Riggs <simon@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 CREATE FUNCTION is DDL for defining what > your database looks like and it should be well defined in perpetuity. So you want your database to work declaratively, but the code that runs against it doesn't need to be. Why would that be? What advantage is gained from having DO blocks potentially fail sometime in the future? Whatever that advantage is, why should functions not also be able to take advantage of that same benefit? > However it's also possible will write DO blocks into their application > code in which case it might be preferable not to have a > default_language GUC which would have to be set correctly for the code > to work. -- Simon Riggs www.2ndQuadrant.com
On sön, 2010-01-24 at 20:32 +0000, 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?
2010/1/25 Peter Eisentraut <peter_e@gmx.net>: > On sön, 2010-01-24 at 20:32 +0000, 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? > isn't it SQL/PSM ? Pavel > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
On mån, 2010-01-25 at 08:09 +0100, Pavel Stehule wrote: > 2010/1/25 Peter Eisentraut <peter_e@gmx.net>: > > On sön, 2010-01-24 at 20:32 +0000, 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? > > > > isn't it SQL/PSM ? No, but if you implement the SQL/PSM part, then those statements become part of the "SQL" language.
2010/1/25 Peter Eisentraut <peter_e@gmx.net>: > On mån, 2010-01-25 at 08:09 +0100, Pavel Stehule wrote: >> 2010/1/25 Peter Eisentraut <peter_e@gmx.net>: >> > On sön, 2010-01-24 at 20:32 +0000, 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? >> > >> >> isn't it SQL/PSM ? > > No, but if you implement the SQL/PSM part, then those statements become > part of the "SQL" language. > ok. i think so default_language could be potential risk for compatibility with standard. Pavel >
On Mon, 2010-01-25 at 09:08 +0200, Peter Eisentraut wrote: > On sön, 2010-01-24 at 20:32 +0000, 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? So the SQL Standard supports the concept of a default language? So should we, though giving the user the choice of what the default should be, standard or otherwise. -- Simon Riggs www.2ndQuadrant.com
On Mon, Jan 25, 2010 at 3:55 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > On Mon, 2010-01-25 at 09:08 +0200, Peter Eisentraut wrote: >> On sön, 2010-01-24 at 20:32 +0000, 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? > > So the SQL Standard supports the concept of a default language? > > So should we, though giving the user the choice of what the default > should be, standard or otherwise. I guess I'll add myself to the list of people who think this is a bad idea, for all the reasons previously stated. 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 had it. +1 for removing default_do_language, too. ...Robert
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 Riggs www.2ndQuadrant.com
--On 25. Januar 2010 09:30:56 -0500 Robert Haas <robertmhaas@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 to use > this even if we had it. > Hmm, even search_path is currently more strict than default_do_language when used interactively: bernd@localhost:bernd #= SET search_path TO 'nonexistingschema'; ERROR: schema "nonexistingschema" does not exist bernd@localhost:bernd #= SET default_do_language TO 'blabla'; SET Doesn't make sense to me... -- Thanks Bernd
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.)
regards, tom lane
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
On Mon, Jan 25, 2010 at 08:26:14PM -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.) The whole default_to_language thing seems like a great way to have spooky breakage at a distance, so +1 for removing it. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
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.) I reserve the option to propose making LANGUAGE SQL the default for CREATE FUNCTION in 9.1, but it's not something we have to worry about now. ;-)
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.