Skip site navigation (1) Skip section navigation (2)

Re: BUG #6496: Why the SQL is not reported as incorrect? Is there a builtin column named "name"?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: luciano(at)geocontrol(dot)com(dot)br
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6496: Why the SQL is not reported as incorrect? Is there a builtin column named "name"?
Date: 2012-02-28 21:47:06
Message-ID: 25074.1330465626@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
luciano(at)geocontrol(dot)com(dot)br writes:
> -- Wrong SQL. Reports no syntax error but yields unexpected data
> SELECT s."name" FROM (SELECT DISTINCT SUBSTRING(bug."name" FROM 1 FOR 3)
> FROM public.is_this_a_bug bug) s;

This is not a bug, exactly, although I'll agree that it's surprising
behavior.  What is happening is that the system is taking s."name" as a
coercion from the subquery's composite rowtype to the string type
"name".  We got enough complaints about that that 9.1 no longer does it,
cf this release note entry:

	Disallow function-style and attribute-style data type casts for
	composite types (Tom Lane)

	For example, disallow composite_value.text and
	text(composite_value). Unintentional uses of this syntax have
	frequently resulted in bug reports; although it was not a bug,
	it seems better to go back to rejecting such expressions. The
	CAST and :: syntaxes are still available for use when a cast of
	an entire composite value is actually intended.

There are also some possibly illuminating details here:
http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=543d22fc7423747afd59fe7214f2ddf6259efc62

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: Rikard PavelicDate: 2012-02-28 21:49:22
Subject: Re: BUG #6489: Alter table with composite type/table
Previous:From: Tom LaneDate: 2012-02-28 21:38:29
Subject: Re: BUG #6497: Error sent to client, but data written anyway

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group