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
Dean Rasheed [EMAIL PROTECTED] writes:
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
Tom Lane wrote:
The ideas I had involved not considering the cast interpretation when
the actual syntax is table.column and some-set-of-other-conditions.
While this is certainly possible to implement, any variant of it will
break the existing 100% equivalence of foo.bar and bar(foo); which
seems
I've just spent a couple of hours tracking down a bug which turned out
to be a typo in my code. What surprises me is that the SQL in question
didn't immediately produce an error. Here's a simplified example:
CREATE TABLE foo(a int, b int);
INSERT INTO foo VALUES(1,2);
SELECT foo.text FROM foo;
Dean Rasheed [EMAIL PROTECTED] writes:
CREATE TABLE foo(a int, b int);
INSERT INTO foo VALUES(1,2);
SELECT foo.text FROM foo;
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
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
