Re: case dumbiness in return from functions

From: Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: case dumbiness in return from functions
Date: 2008-01-18 01:22:53
Message-ID: 20080118022253.6cea47bf@webthatworks.it
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, 17 Jan 2008 19:07:59 -0500
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it> writes:
> > After discovering that pg_get_serial_sequence behaves in a bit
> > strange way[1] when it deals to case sensitiveness
>
> The SQL standard specifies that unquoted identifiers are
> case-insensitive. You're welcome to spell them as camelCase in your
> source code if you feel like it, but don't expect that PG, or any
> other SQL-compliant database, will pay attention.

OK... I did get tricked mixing in the same code base (same file)
access to MS SQL and pg and I confused a

select PiPpO from table in MS SQL

and a

select PiPpO from function() in pg

And I thought that select from table behave differently from select
from functions. Having met the admittedly strange behaviour in
pg_get_serial_sequence that is not case-insensitive I got confused.
All the other select were in fact aliased.

I noticed that the argument of case insensitivity vs. case
preservation is recurrent and I'm not going to argue about it.
I'd prefer to have case preservation but I'd prefer to be able to fly
too. I bet there are good reasons for both even if hope is not going
to die.

Sorry, it was not meant to be disrespectful of the good work you're
doing.

--
Ivan Sergio Borgonovo
http://www.webthatworks.it

In response to

Browse pgsql-general by date

  From Date Subject
Next Message James B. Byrne 2008-01-18 02:28:36 Re: Help with pre-loaded arbitrary key sequences
Previous Message Tom Lane 2008-01-18 00:07:59 Re: case dumbiness in return from functions