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

On Fri, Oct 29, 2010 at 2:07 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> [ 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.

That is correct. Indeed, at this point, I'm not even sure whether I
should have included -performance, here.

>> 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.
>
..

I've spent some time thinking about this. Now, please remember that
I'm not a seasoned postgresql veteran like many of you, but I've been
doing one kind of programming or another for the better part of 20
years. I am also a strong believer in the principle of least surprise.
I say this only so that you might understand better the perspective
I'm coming from. With that said, when I read the first part of your
first item:

> 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.

I feel that, while there may be a fair bit of history here, it's
certainly a bit of a surprise. From my perspective, a.b usually means,
in most other languages (as it does here), "access the named-thing 'b'
from the named-thing 'a' and returns it's value", and whenever
parentheses are involved (especially when in the form "b(a)") it means
"call function 'b' on named-thing 'a' and return the result".

Furthermore, regarding your second point:

> 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.

I've always found the form b(a) to have an implicit (if there is a
*type* b that can take a thing of type a, then do so (essentially an
alternate form of casting). For example, Python and some other
languages behave this way. I'm not sure what I might be doing wrong,
but there appears to be some sort of inconsistency here, however, as
select int(10.1) gives me a syntax error and select 10.1::int does
not.

So what I'm saying is that for people that do not have a significant
background in postgresql that the postquel behavior of treating 'a.b'
the same as b(a) is quite a surprise, whereas treating b(a) the same
as a::b is not (since frequently "types" are treated like functions in
many languages).

Therefore, I suggest that you bear these things in mind when
discussing or contemplating how the syntax should work - you probably
have many more people coming *to* postgresql from other languages than
you have users relying on syntax features of postquel.

If I saw this behavior ( a.b also meaning b(a) ) in another SQL
engine, I would consider it a thoroughly unintuitive wart, however I
also understand the need to balance this with existing applications.

--
Jon