Error codes revisited

greg@turnstep.com writes:

What about a variable that allowed the codes to be switched on so a
number is returned instead of a string? This would be off by default
so as not to break existing applications. Similarly, we can return
other information (FILE, LINE, etc.) with different variables. This
should all be doable without a protocol change, as long as everything
is returned as a string in a standard format.

The *last* thing we need is a half-baked stopgap solution that we'll
have to be backwards-compatible with forevermore. Fix it right or
don't do it at all, is MHO.

There is still barely enough time to do the long-threatened protocol
revision for 7.4, if we suck it up and get started on that now. I've
been avoiding the issue myself, because it seems generally boring and
thankless work, but maybe it's time to face up to it?

regards, tom lane

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The *last* thing we need is a half-baked stopgap solution that we'll
have to be backwards-compatible with forevermore. Fix it right or
don't do it at all, is MHO.

I agree.

There is still barely enough time to do the long-threatened protocol
revision for 7.4, if we suck it up and get started on that now. I've
been avoiding the issue myself, because it seems generally boring and
thankless work, but maybe it's time to face up to it?

Definitely. Sure seems to be a lot involved, looking at the TODO page.
Which brings up another question - if a protocol change doesn't warrant
a bump to 8.0, what does? :)

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200303040645

-----BEGIN PGP SIGNATURE-----
Comment: http://www.turnstep.com/pgp.html

iD8DBQE+ZC1LvJuQZxSWSsgRAkJLAKDUE54ZELrPc4ASqEtwUCk7CYJH/ACfZ7nQ
bLRqMde1T9MDjzmejF+PBis=
=Plww
-----END PGP SIGNATURE-----

On Tue, Mar 04, 2003 at 11:04:03PM -0500, Tom Lane wrote:

There is still barely enough time to do the long-threatened protocol
revision for 7.4, if we suck it up and get started on that now. I've
been avoiding the issue myself, because it seems generally boring and
thankless work, but maybe it's time to face up to it?

Given the repeatedly-asked-for functionalities (like error codes)
for which the stopper has been the long-threatened protocol revision,
I'd think it might be boring, but would hardly be thankless. Heck, I'd
expect a few whoops of joy around the lists.

Ross

Given the repeatedly-asked-for functionalities (like error codes)
for which the stopper has been the long-threatened protocol revision,
I'd think it might be boring, but would hardly be thankless. Heck, I'd

expect a few whoops of joy around the lists.

Yes. Error codes would be great.

Regards, Christoph

Christoph Haller wrote:

Given the repeatedly-asked-for functionalities (like error codes)
for which the stopper has been the long-threatened protocol revision,
I'd think it might be boring, but would hardly be thankless. Heck, I'd

expect a few whoops of joy around the lists.

Yes. Error codes would be great.

Particularly if they arrive in conjunction with Bruce's "Nested
Transaction" implementation. I image many people would like to
create a subtransaction, which, if it fails due to a unique key
violation, could recover and perform an update.

I'd personally like some way of mapping RI-related messages into
application-specific, perhaps localized, messages. Error codes
will provide a nice starting point. Will the action and object
upon which the action is being attempted also be available?

Mike Mascari
mascarm@mascari.com