Re: No error when column doesn't exist

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/

In response to

Responses

Browse pgsql-general by date

  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