Re: [HACKERS] Tricky query, tricky response

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Tricky query, tricky response
Дата
Msg-id 20890.938969598@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Tricky query, tricky response  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Error messages (was Re: [HACKERS] Tricky query, tricky response)
Список pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> 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

Yes, it would.  Are you volunteering to try to make that happen?
(Not for this one case, but for everything?)

There's been some discussion of trying to clean up the error reporting
conventions, and in particular separate internal details (such as which
routine is reporting the error) from the "user level" information.
But a lot of the internal checks are pretty content-free from a user's
point of view, and there's little to be done about that.  (Does
flatten_tlistentry have a clue *why* it got a node type it never heard
of?  Nyet.)  I do not think that a generic "Internal error" message
would be an improvement over what we have, messy though it is.  It's
not a simple problem...
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] NULL as an argument in plpgsql functions
Следующее
От: The Hermit Hacker
Дата:
Сообщение: Re: [HACKERS] RI status report #2