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

From Tom Lane
Subject Re: [HACKERS] Tricky query, tricky response
Date
Msg-id 20890.938969598@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Tricky query, tricky response  (Peter Eisentraut <peter_e@gmx.net>)
Responses Error messages (was Re: [HACKERS] Tricky query, tricky response)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] NULL as an argument in plpgsql functions
Next
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] RI status report #2