Thread: Unquoted column names fold to lower case

On 07/03/2013 11:12 AM, Dev Kumkar wrote:
> All unquoted identifiers are assumed by PostgreSQL to be lower case by
> default. This means
> - SELECT MY_COLUMN FROM my_table
> - SELECT my_column FROM my_table
> - SELECT my_column as MY_COLUMN FROM my_table
> All refer to my_column and has column name in lowercase as my_column.
>
> If the aliases are in upper case and quoted then those are returned in
> upper case.
> - SELECT my_column as "MY_COLUMN" FROM my_table
>
> Is there any workaround to set the alias columns to be returned as
> upper case with adding quotes.

There is no workaround because there is no bug.

> Is there any connection level parameter to flip this behavior?

No.

sorry, but you misunderstand. this is the correct behavior of SQL.

It is part of the specification to do this.

--- On Wed, 7/3/13, Dev Kumkar <devdas.kumkar@gmail.com> wrote:

> From: Dev Kumkar <devdas.kumkar@gmail.com>
> Subject: [SQL] Unquoted column names fold to lower case
> To: pgsql-sql@postgresql.org
> Date: Wednesday, July 3, 2013, 5:12 AM
> Hello,
> 
> All unquoted identifiers are assumed by PostgreSQL to be
> lower case by default. This means 
> - SELECT MY_COLUMN FROM my_table
> - SELECT my_column FROM my_table 
> - SELECT my_column as MY_COLUMN FROM my_table
> 
> All refer to my_column and has column name in lowercase as
> my_column.
> 
> If the aliases are in upper case and quoted then
> those are returned in upper case.
> - SELECT my_column as "MY_COLUMN" FROM
> my_table
> 
> 
> Is there any workaround to set the alias columns
> to be returned as upper case with adding quotes. Is there
> any connection level parameter to flip this behavior?
> 
> Thanks in advance!
> 
> 
> Regards...
> 
> 

Theodore Petrosky, 03.07.2013 15:41:
> sorry, but you misunderstand. this is the correct behavior of SQL.
> 
> It is part of the specification to do this.
> 

Not quite. The SQL standard requires folding to uppercase. 

On Wed, Jul  3, 2013 at 04:16:41PM +0200, Thomas Kellerer wrote:
> Theodore Petrosky, 03.07.2013 15:41:
> > sorry, but you misunderstand. this is the correct behavior of SQL.
> > 
> > It is part of the specification to do this.
> > 
> 
> Not quite. The SQL standard requires folding to uppercase. 

Agreed.  The original poster specifically wanted "MYTABLE" and mytable
to be the same, not "mytable" and mytable.  Postgres is certainly
non-standard in this area.  I think the ability visiually distinguish
lower-case letters better than upper-case letters has led to our
behavior.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

On Wed, Jul  3, 2013 at 09:02:20PM +0530, Dev Kumkar wrote:
> On Wed, Jul 3, 2013 at 8:54 PM, Bruce Momjian <bruce@momjian.us> wrote:
> 
>     Agreed.  The original poster specifically wanted "MYTABLE" and mytable
>     to be the same, not "mytable" and mytable.  Postgres is certainly
>     non-standard in this area.  I think the ability visiually distinguish
>     lower-case letters better than upper-case letters has led to our
>     behavior.
> 
> 
> Not really, actually am looking for column aliases here and not the table. Here
> is the example again when the aliases are unquoted:
> - SELECT my_column as MY_COLUMN FROM my_table
> 
> The above SELECT will fold the alias name as my_column and not MY_COLUMN.

Yes, both the identifier names and alias names are folded to lower case.
I never thought of them as different, but you are right, they are, and
we are non-standard in both areas.  Sorry.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

Dev Kumkar wrote on 03.07.2013 17:50:
> Note that adding quotes for aliases will be blessed by PostgreSQL and
> then those will be folded to upper case BUT this adds up to lot of
> changes in the SQL layer.

I wonder why you need that. I never had the requirement for that.

Which driver/interface do you use that requires an alias to be all uppercase?

Dev Kumkar <devdas.kumkar@gmail.com> writes:
> Any plans to fix this in next release or having a patch to fix this?

No.

This has been discussed (many times) before.  There isn't any feasible
way to change this behavior without breaking an incredible amount of
code, much of which isn't even under our control.  The marginal increase
in standards compliance is not worth the pain --- especially when the
aspect of the standard in question isn't even one that most of us like.
(All-upper-case is hard to read.)

If this is a deal-breaker for you, then I'm sorry, but you need to find
another database.  Postgres settled on this behavior fifteen years ago,
and we're not changing it now.
        regards, tom lane

On Wed, Jul  3, 2013 at 12:20:06PM -0400, Tom Lane wrote:
> Dev Kumkar <devdas.kumkar@gmail.com> writes:
> > Any plans to fix this in next release or having a patch to fix this?
> 
> No.
> 
> This has been discussed (many times) before.  There isn't any feasible
> way to change this behavior without breaking an incredible amount of
> code, much of which isn't even under our control.  The marginal increase
> in standards compliance is not worth the pain --- especially when the
> aspect of the standard in question isn't even one that most of us like.
> (All-upper-case is hard to read.)
> 
> If this is a deal-breaker for you, then I'm sorry, but you need to find
> another database.  Postgres settled on this behavior fifteen years ago,
> and we're not changing it now.

Agreed.  I guess we could add it to the "Features We Do Not Want"
section of the TODO list, but it rarely comes up.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

Dev Kumkar escribió:

> But what I am asking here is if an alias name is provided be it upper case,
> lower case, or a mix then shouldn't it be preserved as as it is given. All
> this talk is when alias names are unquoted, when quoted then its standard
> behavior as seen in other databases.

Aliases are treated just like any other identifier.  The downcasing
happens in the lexer (src/backend/parser/scan.l), which is totally
unaware of the context in which this is happening; so there's no way to
tweak the downcasing behavior for only aliases and not other
identifiers.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Dev Kumkar escribi�:
>> But what I am asking here is if an alias name is provided be it upper case,
>> lower case, or a mix then shouldn't it be preserved as as it is given. All
>> this talk is when alias names are unquoted, when quoted then its standard
>> behavior as seen in other databases.

> Aliases are treated just like any other identifier.  The downcasing
> happens in the lexer (src/backend/parser/scan.l), which is totally
> unaware of the context in which this is happening; so there's no way to
> tweak the downcasing behavior for only aliases and not other
> identifiers.

Quite aside from implementation difficulty, restricting the change to
just column aliases doesn't make it more palatable.  You'd entirely lose
the argument that the change increases spec compliance, because the spec
is perfectly clear that a column alias is an identifier just like any
other.  And you'd still be paying a large part of the application
breakage costs, because the identifiers coming back in query descriptors
are one of the main ways applications would notice such a change.
        regards, tom lane

On Wed, Jul  3, 2013 at 03:47:37PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Dev Kumkar escribi�:
> >> But what I am asking here is if an alias name is provided be it upper case,
> >> lower case, or a mix then shouldn't it be preserved as as it is given. All
> >> this talk is when alias names are unquoted, when quoted then its standard
> >> behavior as seen in other databases.
> 
> > Aliases are treated just like any other identifier.  The downcasing
> > happens in the lexer (src/backend/parser/scan.l), which is totally
> > unaware of the context in which this is happening; so there's no way to
> > tweak the downcasing behavior for only aliases and not other
> > identifiers.
> 
> Quite aside from implementation difficulty, restricting the change to
> just column aliases doesn't make it more palatable.  You'd entirely lose
> the argument that the change increases spec compliance, because the spec
> is perfectly clear that a column alias is an identifier just like any
> other.  And you'd still be paying a large part of the application
> breakage costs, because the identifiers coming back in query descriptors
> are one of the main ways applications would notice such a change.

And let's not forget that column aliases can be used as indentifiers in
queries:
test=> SELECT 1 AS xtest-> ORDER BY x; x--- 1(1 row)
test=> SELECT 1 AS "X"ORDER BY x;ERROR:  column "x" does not existLINE 2: ORDER BY x;

Changing this would mean that the same identifier would have different
case-folding rules depending on where it appeared in the query.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

On Thu, Jul  4, 2013 at 02:00:24AM +0530, Dev Kumkar wrote:
> On Thu, Jul 4, 2013 at 1:36 AM, Bruce Momjian <bruce@momjian.us> wrote:
> 
>     And let's not forget that column aliases can be used as indentifiers in
>     queries:
> 
>             test=> SELECT 1 AS x
>             test-> ORDER BY x;
>              x
>             ---
>              1
>             (1 row)
> 
>             test=> SELECT 1 AS "X"
>             ORDER BY x;
>             ERROR:  column "x" does not exist
>             LINE 2: ORDER BY x;
> 
>     Changing this would mean that the same identifier would have different
>     case-folding rules depending on where it appeared in the query.
> 
>  
> Sorry but I am not sure about your point here. Currently if the alias is quoted
> then same needs to be used in queries as identifies:
> SELECT 1 AS "X"
>         ORDER BY "X";

You would need to double-quote 'x' in the ORDER BY, but not in the
target list (because case would be preserved there)  --- that is
confusing.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +

Alvaro Herrera-9 wrote
> Dev Kumkar escribió:
>
> Aliases are treated just like any other identifier.  The downcasing
> happens in the lexer (src/backend/parser/scan.l), which is totally
> unaware of the context in which this is happening; so there's no way to
> tweak the downcasing behavior for only aliases and not other
> identifiers.

Hi, sorry I know this is an old thread, but I'm running up against the same
issue.

This statement seems to contradict the PostgreSQL documentation regarding
identifiers. From "4.1.1. Identifiers and Key Words" in
http://www.postgresql.org/docs/8.0/static/sql-syntax.html it states

"Quoting an identifier also makes it case-sensitive, whereas unquoted names
are always folded to lower case. For example, the identifiers FOO, foo, and
"foo" are considered the same by PostgreSQL, but "Foo" and "FOO" are
different from these three and each other."

But your statement suggests that even though aliases are treated like any
other identifier, and you can quote an identifier to make it case sensitive,
this is not happening. To me this sounds like a bug.
Thoughts?





--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Unquoted-column-names-fold-to-lower-case-tp5762315p5805199.html
Sent from the PostgreSQL - sql mailing list archive at Nabble.com.