Re: [PERFORM] typoed column name, but postgres didn't grump - Mailing list pgsql-bugs

On Fri, Oct 29, 2010 at 3:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> [ please continue any further discussion in pgsql-bugs only ]
>
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> BTW this seems pretty far off-topic for pgsql-performance.
>
>> It is once you understand what's happening. =A0It 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. =A0If you happen to have a reference or search criteria
>> for a previous thread, could you post it? =A0Otherwise, a brief
>> explanation of why this is considered a feature worth keeping would
>> be good. =A0I 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. =A0This 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. =A0This is
> just as ancient as #1. =A0It 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. =A0We'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. =A0I 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. =A0The 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. =A0If we slice off some other part of the
> functionality, we risk breaking apps that've worked for many years.

Well, then let's do that.  It's not the exact fix I'd pick, but it's
clearly better than nothing, so I'm willing to sign on to it as a
compromise position.

--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company