Re: When did this behavior change (and where else might it bite me)?
| От | Steve Atkins |
|---|---|
| Тема | Re: When did this behavior change (and where else might it bite me)? |
| Дата | |
| Msg-id | AC50521D-0EF8-4C58-AD59-22FD41FE03BC@blighty.com обсуждение исходный текст |
| Ответ на | When did this behavior change (and where else might it bite me)? (Jeff Amiel <becauseimjeff@yahoo.com>) |
| Список | pgsql-general |
On Mar 18, 2013, at 9:49 AM, Jeff Amiel <becauseimjeff@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
totype "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
frequentlyresulted in bug reports; although it was not a bug, it seems better to go back to rejecting such expressions.
TheCASTand :: syntaxes are still available for use when a cast of an entire composite value is actually intended.
Cheers,
Steve
В списке pgsql-general по дате отправления: