From: | Dean Rasheed <dean_rasheed(at)hotmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: No error when column doesn't exist |
Date: | 2008-09-11 07:57:16 |
Message-ID: | BAY102-W665CB4376DA7ACF2A3111F2560@phx.gbl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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/
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2008-09-11 08:01:23 | Re: declare column update expression |
Previous Message | Chris Velevitch | 2008-09-11 07:35:34 | declare column update expression |