Thank you Tom and Neil for your replies.

> > 2/ If there is no convention is it ok to use the letter 'x' for all our
> > State codes?
> Why would you want to do that?
I think that I have missed explaining a point. We are developing a
proprietary extension to PostgreSQL. This means that some errors that are
thrown in our extension will never be thrown by the OSS community code.
Thus, for these cases we should use a code that will not be used by the OSS
community (hopefully) so we will not have to keep changing it in future
updates. I hope i am clear? Thus, we invented using the letter 'x', as it
seems a bit out of the way...

> > 2/ If we have some States that might become common to the code in
> > future releases, can we give them in as patches?
> What's the value in keeping these the same? (If a client is already
> looking for a specific error code, it doesn't seem too onerous for them
> to need to look for two.)
In keeping one state code to mean one condition, it would mean that there is
less confusion on the user's side. For example, after applying our
extension, if the same code were not to be used, two different codes might
mean the same condition. Like 53799 and 53P19 (fictitious numbers) might
both mean "insufficient space on tablespace XXX". This is probably a bad
thing from the user's perspective.

Also, it wouldn't mean that there is better code re-use?

> I would advise taking a good look at other DBs to see if you can find a
> usable SQLSTATE before you go inventing new ones.  If you do have to
> invent a new one then use a 'P' code.  This is a shared namespace after
> all, so we shouldn't randomly use up new ranges of codes.

With regards to the error codes that might be thrown by PostgreSQL
community, I will follow Tom's advice and look into DB2 and other databases
to look for codes in order to patch.

Thanks again!


This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 
481. It is confidential to the ordinary user of the email address to which it was 
addressed and may contain copyright and/or legally privileged information. No one else 
may read, print, store, copy or forward all or any of it or its attachments. If you 
receive this email in error, please return to sender. Thank you.

If you do not wish to receive commercial email messages from Fujitsu Australia 
Software Technology Pty Ltd, please email [EMAIL PROTECTED]

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Reply via email to