Re: No error when column doesn't exist - Mailing list pgsql-general

From Dean Rasheed
Subject Re: No error when column doesn't exist
Date
Msg-id BAY102-W665CB4376DA7ACF2A3111F2560@phx.gbl
Whole thread Raw
In response to Re: No error when column doesn't exist  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: No error when column doesn't exist  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
> 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.
>

Thanks for the explanation. I see what's going on now.

> 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.
>

... and also any user defined domains based on those, which is
what I actually had. I was unlucky enough that the row text matched
the regexp on my domain, so my typo went unnoticed for a while ;-(

> 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.
>
>             regards, tom lane

OK, I can live with that. At least I know what to look out for now!

Cheers, Dean

_________________________________________________________________
Win New York holidays with Kellogg’s & Live Search
http://clk.atdmt.com/UKM/go/111354033/direct/01/

pgsql-general by date:

Previous
From: "Chris Velevitch"
Date:
Subject: declare column update expression
Next
From: "Pavel Stehule"
Date:
Subject: Re: declare column update expression