X-Original-To: pgsql-hackers@postgreSQL.org
Received: from sss.pgh.pa.us (unknown [192.204.191.242])
	by postgresql.org (Postfix) with ESMTP
	id C0A6A474E44; Fri, 14 Mar 2003 23:48:07 -0500 (EST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.12.8/8.12.8) with ESMTP id h2F4mBub026430;
	Fri, 14 Mar 2003 23:48:11 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
Cc: pgsql-hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] Upgrading the backend's error-message infrastructure
In-reply-to: <25281.1047690137@sss.pgh.pa.us> 
References: <Pine.LNX.4.44.0303132349500.1617-100000@peter.localdomain>
	<25281.1047690137@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Fri, 14 Mar 2003 20:02:17 -0500"
Date: Fri, 14 Mar 2003 23:48:10 -0500
Message-ID: <26429.1047703690@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Archive-Number: 200303/645
X-Sequence-Number: 36891

I said:
> I had missed the relevance of <condition information item name>, will
> go look at it.

It looks to me like support of the SQL condition information items would
require adding about two dozen optional fields to my spec for the Error
protocol message, and the same number of optional errFOO(...)
subroutines in the ereport() interface (only two or three of which would
be likely to get invoked in any one ereport instance).  This is a bit
more than I'd been visualizing, but AFAICS the proposed mechanisms would
work perfectly well with it.  I won't bore the list with a detailed spec
for the individual items --- they seem pretty obvious.

Given that we now need order-of-thirty possible field types, do you feel
uncomfortable with a single-byte field identifier in the FE/BE protocol?
I'm still leaning that way on the grounds of compactness and programming
simplicity, but I can see where someone might want to argue it won't do
in the long run.

			regards, tom lane