Re: No error when column doesn't exist

From: Artacus <artacus(at)comcast(dot)net>
To: PostgreSQL <pgsql-general(at)postgresql(dot)org>
Subject: Re: No error when column doesn't exist
Date: 2008-09-11 05:45:28
Message-ID: 48C8B078.7000701@comcast.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

>> I expected that to generate an error: column foo.text does not exist.
>> Instead it treats "foo.text" as "foo.*::text AS text":
>> Is this a feature or a bug?
>
> Hmm. It's a feature, but maybe a dangerous one. The expression is
> being treated as text(foo), which is intentional in order to allow
> use of functions as if they were virtual columns. However, then it
> decides that what you've got there is a cast request. There wasn't
> any ability to cast composite types to text before 8.3, so this fails
> in the expected way in 8.2 and before; but in 8.3 the cast
> interpretation succeeds, and away we go.
>
> foo.char and foo.varchar have similarly unexpected behavior; I think
> that's probably the end of it, though, since those are the only types
> that CoerceViaIO will take as targets.
>
> Maybe we could/should restrict things so that the syntax continues to
> fail, but I can't think of any restrictions that don't seem like warts.
> What's worse, they might break stuff that used to work.

I like that functionality and think the behavior is as it should be.
Best practice is to not name columns with reserved words. So maybe we
could update the manual with another reason not to use SQL reserved
words as column names.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tobias Anstett 2008-09-11 06:42:07 How to check if an array is empty
Previous Message Greg Smith 2008-09-11 05:43:43 Re: psql scripting tutorials