Skip site navigation (1) Skip section navigation (2)

Re: Correcting Error message

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Glaesemann <grzm(at)seespotcode(dot)net>
Cc: Piyush Newe <piyush(dot)newe(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Correcting Error message
Date: 2010-02-27 02:03:08
Message-ID: 10088.1267236188@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Michael Glaesemann <grzm(at)seespotcode(dot)net> writes:
> On Feb 26, 2010, at 3:30 , Piyush Newe wrote:
>> SELECT (footable.*).foofunc FROM footable;
>> ERROR:  column footable.foofunc does not exist

> Is that calling syntax correct?  I'd think it should be:
> SELECT foofunc(footable.*, 10) FROM footable;

He's relying on the f(x) === x.f syntactic equivalence, as per the
comments for ParseFuncOrColumn:
 
 *  For historical reasons, Postgres tries to treat the notations tab.col
 *  and col(tab) as equivalent: if a single-argument function call has an
 *  argument of complex type and the (unqualified) function name matches
 *  any attribute of the type, we take it as a column projection.  Conversely
 *  a function of a single complex-type argument can be written like a
 *  column reference, allowing functions to act like computed columns.

or see the user-facing documentation near the end of section 34.4.2:
http://www.postgresql.org/docs/8.4/static/xfunc-sql.html#AEN43797

It's still an unnecessarily awkward example though, as you could just
as well write
	SELECT footable.foofunc FROM footable;

> Note there are two arguments to foofunc (in either version)

... and the example also relies on the presence of default arguments for
both functions.  This makes both of them match a single-argument call,
resulting in an ambiguous-function situation.  The proposed change
would cause it to actually throw an "ambiguous function" error.

I'm not very sure if the proposed change is an improvement or not.
The given message is 100% correct: there is no such column.  Now
if you were intending a function call, it would be more useful if it
complained about "ambiguous function" instead, but if you really just
typo'd a column name then that could be mighty confusing.  I'm inclined
to think that if you were intending a function call, you'd be most
likely to write it as a function call, especially if you didn't
understand why you were getting an error; and then you'd get the
message that was helpful for that case.  So I'm inclined to leave
the code alone.  It's a judgment call though, without a doubt.

It might help to make a decision if we saw a real-world case where
this happened and the other error message would be more desirable.
The example seems a bit contrived to me; who'd really create such a
pair of functions and then try to invoke them this way?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Greg StarkDate: 2010-02-27 02:30:56
Subject: Re: Hot Standby query cancellation and Streaming Replication integration
Previous:From: Greg SmithDate: 2010-02-27 01:53:13
Subject: Re: Hot Standby query cancellation and Streaming Replication integration

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group