Re: [HACKERS] Tricky query, tricky response - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [HACKERS] Tricky query, tricky response
Date
Msg-id Pine.LNX.4.10.9910030715590.366-100000@peter-e.yi.org
Whole thread Raw
In response to Re: [HACKERS] Tricky query, tricky response  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Tricky query, tricky response  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Oct 2, Tom Lane mentioned:

> Nope: no sub-selects in target list.
> 
> I'm hoping to fix that soon, but if you want psql to continue to work
> with pre-6.6 backends then you'll have to use a different approach.

Question number one is: Do I? Yeah, okay :)

Anyway, I thought wouldn't a more, um, user-friendly error message like
ERROR: Subselects are not allowed in target list.
be more desirable than
ERROR:  flatten_tlistentry: Cannot handle node type 108

If _I_ read the latter I can at least suspect that there is a problem in
the query tree, but Joe User that just learned about inodes the other day
is going to think his system is broken is all sorts of ways.

Another example is
FATAL 1:  SetUserId: user 'joeschmoe' is not in 'pg_shadow'
clearly not as nice as
FATAL ERROR: 'joeschmoe' is not a valid database user.

(Also, if you want to be really secure you wouldn't give them the
information that 'joeschmoe' is not a valid user but rather just return
"Permission denied" or "Authentication failed". -- cf. login(1) )

I think that ought to be a TODO item, right above
* Allow international error message support and add error codes
Perhaps it's even the same in essence.

-- 
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e



pgsql-hackers by date:

Previous
From: "D'Arcy" "J.M." Cain
Date:
Subject: Re: [HACKERS] NULL as an argument in plpgsql functions
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] NULL as an argument in plpgsql functions