Re: [HACKERS] [INTERFACES] Upgrading the backend's error-message infrastructure
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Tom Lane writes: >> MMessage --- the string is the primary error message (localized). >> DDetail --- secondary error message, carrying more detail about >> the problem (localized). >> HHint --- a suggestion what to do about the error (localized). > Client interfaces for the most part only have the notion of a single > "message text". (And keep in mind that the definitions of most interfaces > are outside our control: JDBC, ODBC, ECPG, Perl DBI, PHP, etc.) So what > kind of functionality is needed so that standardized interfaces can get at > any of the provided details and hints? I think this is a matter to be solved at the level of the API of each client library. For example, libpq's PQerrorMessage would presumably construct some unified string out of these three fields and the error severity; plus we'd add new calls to extract the individual fields. I do not think it's appropriate to try to control this from the server side of things. > Also, how do we control what amount of detail is written to the server > log? Some GUC variables would do for that, probably, if we think it's a good idea to be selective (a proposition I'm dubious about). regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [INTERFACES] Upgrading the backend's error-message infrastructure
Tom Lane writes: > M Message --- the string is the primary error message (localized). > D Detail --- secondary error message, carrying more detail about > the problem (localized). > H Hint --- a suggestion what to do about the error (localized). Client interfaces for the most part only have the notion of a single "message text". (And keep in mind that the definitions of most interfaces are outside our control: JDBC, ODBC, ECPG, Perl DBI, PHP, etc.) So what kind of functionality is needed so that standardized interfaces can get at any of the provided details and hints? Maybe this doesn't need to be solved at the protocol layer. Instead a server-side switch regulates the detail of the provided messages. Also, how do we control what amount of detail is written to the server log? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [INTERFACES] Upgrading the backend's error-message infrastructure
Tom Lane writes: > Hmm. I can't see any advantage to these over assigning our own codes; > ours would have at least *some* mnemonic value, rather than being chosen > completely at random ... One advantage is that interfaces that are required to use these constants would not need an internal translation table. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [INTERFACES] Upgrading the backend's error-message infrastructure
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Tom Lane writes: >> 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? > There's a possible solution: SQL99 part 3 defines numerical codes for > each of these fields (table 12/section 5.14). The codes are between > around 0 and 40. Hmm. I can't see any advantage to these over assigning our own codes; ours would have at least *some* mnemonic value, rather than being chosen completely at random ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [INTERFACES] Upgrading the backend's error-message infrastructure
Tom Lane writes: > 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. There's a possible solution: SQL99 part 3 defines numerical codes for each of these fields (table 12/section 5.14). The codes are between around 0 and 40. (Don't be confused by the negative code numbers in the table; those are only for use within ODBC.) -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [INTERFACES] Upgrading the backend's error-message infrastructure
I said: > I had missed the relevance of , 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [INTERFACES] Upgrading the backend's error-message infrastructure
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> where the x's are single-character field identifiers.
> I think we need more flexible field tags. The SQL standards has
> provisions for more fields accompanying error messages, such as the name
> of the affected table.
Well, we can certainly add more tags, but do you foresee needing more
than 50 or so? I'd prefer to stick to single-byte tags for space
reasons, even if they stop being very mnemonic at some point. As long
as we don't run out of printable ASCII characters, it's easy on both the
sending and receiving sides to cope with single-byte tags.
I had missed the relevance of , will
go look at it.
>> NOTE: a variant scheme would treat the SQLSTATE code as an optional
>> parameter too, ie you'd write
>> ereport(ERROR, errcode(ERRCODE_xxx), ...
> I have a feeling that most errors are of the "internal" class, either
> those that are really a kind of assertion check (perhaps we should
> consider an enhanced API for those in the future) or failed system or
> library calls. We would need to analyze that feeling a little more, but
> if it's true then we might save some effort if the default error code
> were "internal".
Yeah, that was in the back of my mind too, but I hadn't got round to
counting to see if it's right.
> Then again, it might seem better if the default error code were closer in
> nature to "default", meaning an unspecified error if the programmer
> couldn't think of one (consider loadable modules).
Unconverted elog's will produce some such SQLSTATE, but if we can't
think of a better SQLSTATE for ones we *have* converted then I think we
need to think harder ;-)
This brings up something I had wanted to start a separate thread for,
which is exactly what SQLSTATEs do we want to define beyond those given
in the spec. Any thoughts?
> Speaking of loadable modules, one feature that would be useful would be
> the ability to select a different message catalog for translations.
> Right now an elog(ERROR, "foo") call in a loaded module looks up "foo" in
> the message catalog provided by the main server but it probably won't be
> there. This could look like
> ereport(ERROR, errmsgdomain("plpgsql"), "...")
Rather than cluttering the individual ereport calls with such a thing,
can't a loadable module just do something when it is loaded to add its
message catalog file to the set that will be searched? (But it is
interesting that we *could* do it as you suggest. This mechanism is
more flexible than I realized...)
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [INTERFACES] Upgrading the backend's error-message infrastructure
Tom Lane writes:
> Error and Notice (maybe also Notify?) msgs will have this structure:
>
> E
> x string \0
> x string \0
> x string \0
> \0
>
> where the x's are single-character field identifiers.
I think we need more flexible field tags. The SQL standards has
provisions for more fields accompanying error messages, such as the name
of the affected table. (See for a the
list.) I think it would be nice if applications could easily access, say,
the name of the constraint that was violated.
> NOTE: a variant scheme would treat the SQLSTATE code as an optional
> parameter too, ie you'd write
> ereport(ERROR, errcode(ERRCODE_xxx), ...
> This would just be excess verbiage if most or all ereport calls specify
> error codes --- but for the errmsg_internal case we could leave out
> errcode(), expecting it to default to "internal error". Any thoughts on
> which way is better?
I have a feeling that most errors are of the "internal" class, either
those that are really a kind of assertion check (perhaps we should
consider an enhanced API for those in the future) or failed system or
library calls. We would need to analyze that feeling a little more, but
if it's true then we might save some effort if the default error code
were "internal".
Then again, it might seem better if the default error code were closer in
nature to "default", meaning an unspecified error if the programmer
couldn't think of one (consider loadable modules).
Speaking of loadable modules, one feature that would be useful would be
the ability to select a different message catalog for translations.
Right now an elog(ERROR, "foo") call in a loaded module looks up "foo" in
the message catalog provided by the main server but it probably won't be
there. This could look like
ereport(ERROR, errmsgdomain("plpgsql"), "...")
or maybe
ereport_domain("plpgsql", ERROR, ...);
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [INTERFACES] Upgrading the backend's error-message infrastructure
Jean-Luc Lachance <[EMAIL PROTECTED]> writes: > Why trade 5 characters for a 4 byte integer -- a saving of 1 byte? It's more than that: in one case you have something on the order of a "load immediate" instruction, whereas in the other case the code is like "load pointer to global string", plus you need a 6-byte string literal (maybe costing you 8 bytes depending on alignment considerations). Also, depending on your machine's approach to addressing of global data, that "load pointer" thingy could be multiple instructions. So we're talking about at least six, possibly 8-12 bytes per elog call --- and there are thousands of 'em in the backend. Admittedly, it's a micro-optimization, but it seems worth doing since it won't have any direct impact on code legibility. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
