Re: [HACKERS] Tricky query, tricky response

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: [HACKERS] Tricky query, tricky response
Дата
Msg-id Pine.LNX.4.10.9910030715590.366-100000@peter-e.yi.org
обсуждение исходный текст
Ответ на Re: [HACKERS] Tricky query, tricky response  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Tricky query, tricky response
Список 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 по дате отправления:

Предыдущее
От: "D'Arcy" "J.M." Cain
Дата:
Сообщение: Re: [HACKERS] NULL as an argument in plpgsql functions
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] NULL as an argument in plpgsql functions