Re: default_language
От | Jeff Davis |
---|---|
Тема | Re: default_language |
Дата | |
Msg-id | 1264367553.29919.293.camel@jdavis обсуждение исходный текст |
Ответ на | default_language (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: default_language
|
Список | 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 по дате отправления: