language name case sensitivity, also known as plpgsql <> 'PLpgSQL'

On 26 March 2012 16:30, Gregg Jaskiewicz <gryzman@gmail.com> wrote:

Folks,
I'm testing some code on 9.2dev (trunk), and I've noticed that
postgresql seems to be fussy about language case when creating a
function.
So for instance:
create function foo() returns int AS $$ BEGIN return 1; END; $$
LANGUAGE 'PLpgSQL';

Will be fine on 8.3 (my current version used in product), but not so
fine when using 9.2dev.

I think this is obviously a regression. What you say ?

Probably something to do with this:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=67dc4eed42186ba6a2456578899bfd38d003201a

--
Thom

On 26 March 2012 16:41, Thom Brown <thom@linux.com> wrote:

Probably something to do with this:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=67dc4eed42186ba6a2456578899bfd38d003201a

Sounds very plausible.
Would you call it a regression ? I would say so, but not sure what
would be an argument on the other side then ?
Mine is, that some of currently used code will fail on this for no
apparent benefit.
Plus the bit where he says, that params in quotes will be lowercased -
obviously doesn't work then

--
GJ

Gregg Jaskiewicz <gryzman@gmail.com> writes:

On 26 March 2012 16:41, Thom Brown <thom@linux.com> wrote:

Probably something to do with this:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=67dc4eed42186ba6a2456578899bfd38d003201a

Would you call it a regression ?

It's an intentional change to make handling of language names less
bizarrely different from every other name in SQL. Personally, I'd
recommend getting rid of the single quotes. Use of a string literal for
a language name has been poor style since 7.2 or thereabouts, and it is
foreseeable that at some point we'd stop accepting string literals for
this purpose altogether.

regards, tom lane