Thread: Error codes revisited
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As promised, I've been looking over the error handling (especially the archived discussions) and it's a real rat's nest. :) I'm not sure where we should start, but just getting some error codes enabled and out there would be a great start. The protocol changes can come later. And the codes should not be part of the string. 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. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200303041516 -----BEGIN PGP SIGNATURE----- Comment: http://www.turnstep.com/pgp.html iD8DBQE+ZQo2vJuQZxSWSsgRAiKiAKDImuVDD5v4mvY1ClrTo9YrYFlDogCgwz1C Q/DS7rHZ2XWCPuZd8oQoVeA= =ixmb -----END PGP SIGNATURE-----
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. Errorcodes 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