Обсуждение: Policy on schema-qualified names
I wonder if there is a policy on when schema-qualified names should be used in ereport/elog messages. At the moment this doesn't seem to be consistent, even within the same command: template1=# VACUUM verbose t; INFO: vacuuming "public.t" [...] template1=# VACUUM verbose tv; WARNING: skipping "tv" --- cannot vacuum indexes, views, or special system tables When actually doing its work, VACUUM schema-qualifies the name of the object but when it refuses to do so it doesn't... Joachim
Joachim Wieland wrote: > I wonder if there is a policy on when schema-qualified names should > be used in ereport/elog messages. If it's not too hard to do, I would add the schema name in most places. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut <peter_e@gmx.net> writes:
> Joachim Wieland wrote:
>> I wonder if there is a policy on when schema-qualified names should
>> be used in ereport/elog messages.
> If it's not too hard to do, I would add the schema name in most places.
Actually, it's semi-consciously omitted in most places on the grounds
that (1) it's seldom necessary to identify the problem, and (2) in many
error messages it would contribute to violating the "make it fit on one
line" style guideline.
regards, tom lane
On Mon, Jan 30, 2006 at 05:10:03PM -0500, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > Joachim Wieland wrote: > >> I wonder if there is a policy on when schema-qualified names should > >> be used in ereport/elog messages. > > If it's not too hard to do, I would add the schema name in most places. > Actually, it's semi-consciously omitted in most places on the grounds > that (1) it's seldom necessary to identify the problem, and (2) in many > error messages it would contribute to violating the "make it fit on one > line" style guideline. (1) is probably true but it wouldn't hurt to include the schema name there either. Making assumptions on the length of an error message seems to be moot anyway, since you don't know the length of the names of user defined objects in advance, nor do you know the length of the translated message strings in different languages. So you just lose precision for a questionable gain. Joachim
Joachim Wieland <joe@mcknight.de> writes:
> Making assumptions on the length of an error message seems to be moot
> anyway, since you don't know the length of the names of user defined objects
> in advance, nor do you know the length of the translated message strings in
> different languages.
It's certainly all pretty fuzzy, but adding an additional name to an
error message has to be seen as a significant increase in the message
length. The worst cases are for things like foreign-key messages, where
you'd be putting *two* additional identifiers into the message.
I think the precision argument is misguided. The direction that we
ought to be going in is to add separate fields to error reports that
contain just the names of the relevant objects (without any other
decoration). This is needed anyway to allow client-side programs to
extract the information without having to parse human-readable text
messages ... and IIRC it's required by some part of the SQL spec, too.
I imagine such fields wouldn't be shown at default verbosity, but you
could look at them if you needed to find out which schema a referenced
object belonged to.
regards, tom lane
On Tue, Jan 31, 2006 at 01:46:42PM -0500, Tom Lane wrote: > The direction that we ought to be going in is to add separate fields to > error reports that contain just the names of the relevant objects (without > any other decoration). This is needed anyway to allow client-side > programs to extract the information without having to parse human-readable > text messages ... and IIRC it's required by some part of the SQL spec, > too. Agreed. I didn't know about that part but with this in mind it would be a waste of time to check all of the the messages at this time and make them conform in some way. Thanks for the explanation, Joachim