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
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
> wha
> 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 ca
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 f
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.
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;
I
