Re: [PERFORM] typoed column name, but postgres didn't grump

[ please continue any further discussion in pgsql-bugs only ]

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> BTW this seems pretty far off-topic for pgsql-performance.

> It is once you understand what's happening. It was probably the 11+
> minutes for the mistyped query run, versus the 28 ms without the
> typo, that led them to this list.

> I remembered this as an issued that has come up before, but couldn't
> come up with good search criteria for finding the old thread before
> you posted. If you happen to have a reference or search criteria
> for a previous thread, could you post it? Otherwise, a brief
> explanation of why this is considered a feature worth keeping would
> be good. I know it has been explained before, but it just looks
> wrong, on the face of it.

What's going on here is an unpleasant interaction of several different
features:

1. The notations a.b and b(a) are equivalent: either one can mean the
column b of a table a, or an invocation of a function b() that takes
a's composite type as parameter. This is an ancient PostQUEL-ism,
but we've preserved it because it is helpful for things like
emulating computed columns via functions.

2. The notation t(x) will be taken to mean x::t if there's no function
t() taking x's type, but there is a cast from x's type to t. This is
just as ancient as #1. It doesn't really add any functionality, but
I believe we would break a whole lot of users' code if we took it away.
Because of #1, this also means that x.t could mean x::t.

3. As of 8.4 or so, there are built-in casts available from pretty much
any type (including composites) to all the built-in string types, viz
text, varchar, bpchar, name.

Upshot is that t.name is a cast to type "name" if there's no column or
user-defined function that can match the call. We've seen bug reports
on this with respect to both the "name" and "text" cases, though I'm
too lazy to trawl the archives for them just now.

So, if you want to throw an error for this, you have to choose which
of these other things you want to break. I think if I had to pick a
proposal, I'd say we should disable #2 for the specific case of casting
a composite type to something else. The intentional uses I've seen were
all scalar types; and before 8.4 there was no built-in functionality
that such a call could match. If we slice off some other part of the
functionality, we risk breaking apps that've worked for many years.

regards, tom lane