Re: When did this behavior change (and where else might it bite me)? - Mailing list pgsql-general

From Tom Lane
Subject Re: When did this behavior change (and where else might it bite me)?
Date
Msg-id 11060.1363628543@sss.pgh.pa.us
Whole thread Raw
In response to When did this behavior change (and where else might it bite me)?  (Jeff Amiel <becauseimjeff@yahoo.com>)
List pgsql-general
Jeff Amiel <becauseimjeff@yahoo.com> writes:
> 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 changed in this 9.1 patch:

commit 543d22fc7423747afd59fe7214f2ddf6259efc62
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Sun Nov 7 13:03:19 2010 -0500

    Prevent invoking I/O conversion casts via functional/attribute notation.

    PG 8.4 added a built-in feature for casting pretty much any data type to
    string types (text, varchar, etc).  We allowed this to work in any of the
    historically-allowed syntaxes: CAST(x AS text), x::text, text(x), or
    x.text.  However, multiple complaints have shown that it's too easy to
    invoke such casts unintentionally in the latter two styles, particularly
    field selection.  To cure the problem with the narrowest possible change
    of behavior, disallow use of I/O conversion casts from composite types to
    string types via functional/attribute syntax.  The new functionality is
    still available via cast syntax.

    In passing, document the equivalence of functional and attribute syntax
    in a more visible place.

It's not that "name" is a reserved word or not, it's that it's the name
of a datatype that's considered to be of string category; so you can
cast just about anything to a name.

            regards, tom lane


pgsql-general by date:

Previous
From: Steve Atkins
Date:
Subject: Re: When did this behavior change (and where else might it bite me)?
Next
From: Rob Sargent
Date:
Subject: regexp_replace failing on 9.0.4