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 <condition information item name> 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