Re: default_language - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: default_language
Date
Msg-id 1264367553.29919.293.camel@jdavis
Whole thread Raw
In response to default_language  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: default_language
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: further explain changes
Next
From: Dimitri Fontaine
Date:
Subject: Re: default_language