On Mar 18, 2013, at 9:49 AM, Jeff Amiel <becauseimj...@yahoo.com> wrote:
> In prepping for an upgrade to 9.2.3, I stumbled across this:
>
> CREATE TABLE foo
> (
> myint integer,
> string1 text,
> string2 text
> )
> WITH (
> OIDS=FALSE
> );
>
> insert into foo values (12345,'Y','N');
>
> select * from foo f where f.myint = 12345 or f.name='Y'
>
> In 9.2.3, this returns:
> ERROR: column f.name does not exist
> LINE 1: select * from foo f where myint = 12345 or f.name='Y'
>
> in 8.4.6 ,this returns no error (and gives me the row from the table)
That's (unintentionally) an attribute style data type cast - bar.name is the
same as name(bar), and tries to cast bar to type "name" (an internal-use string
type)
Try "select foo from foo", "select name(foo::text) from foo" and "select
name(foo) from foo" to see what's going on.
That was tightened up in 9.1, I think:
Casting
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 CASTand :: syntaxes are still available for use when a cast of
an entire composite value is actually intended.
Cheers,
Steve
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
