At 00:35 22/03/01 -0500, Tom Lane wrote:
>Philip Warner <[EMAIL PROTECTED]> writes:
>> This is a problem, I agree - but a procedural one. We need to make
>> registering messages easy. To do this, rather than having a central message
>> file, perhaps do the following:
>
>> - allow multiple message
Philip Warner <[EMAIL PROTECTED]> writes:
> This is a problem, I agree - but a procedural one. We need to make
> registering messages easy. To do this, rather than having a central message
> file, perhaps do the following:
> - allow multiple message files (which can be processed to produce .h
> f
At 23:24 21/03/01 -0500, Tom Lane wrote:
>I've pretty much got to agree with Peter on both of these points.
Damn.
>Philip Warner <[EMAIL PROTECTED]> writes:
>> At 22:03 21/03/01 +0100, Peter Eisentraut wrote:
> elogc(ERROR, PGERR_FUNCNOTYPE, ...)
>>>
>>> This is going to be a disaster for
At 22:03 21/03/01 +0100, Peter Eisentraut wrote:
>
>This is going to be a disaster for the coder. Every time you look at an
>elog you don't know what it does? Is the first arg a %s or a %d? What's
>the first %s, what the second?
FWIW, I did a quick scan for elog in PG and found:
- 6856 calls (
I've pretty much got to agree with Peter on both of these points.
Philip Warner <[EMAIL PROTECTED]> writes:
> At 22:03 21/03/01 +0100, Peter Eisentraut wrote:
elogc(ERROR, PGERR_FUNCNOTYPE, ...)
>>
>> This is going to be a disaster for the coder. Every time you look at an
>> elog you don't
At 22:03 21/03/01 +0100, Peter Eisentraut wrote:
>Philip Warner writes:
>
>> If the motivation behind this is to alloy easy translation to SQL error
>> codes, then I suggest we have an error definition file with explicit
>> translation:
>>
>> Code SQL Text
>> PGERR_TYPALREXI 02xxx "
Philip Warner writes:
> If the motivation behind this is to alloy easy translation to SQL error
> codes, then I suggest we have an error definition file with explicit
> translation:
>
> Code SQL Text
> PGERR_TYPALREXI 02xxx "type %s cannot be created because it already exists"
> PG
At 09:43 21/03/01 +1100, Philip Warner wrote:
>
>Code SQL Text
>PGERR_TYPALREXI 02xxx "type %s cannot be created because it already exists"
>PGERR_FUNCNOTYPE 02xxx "type %s used as argument %d of function %s doesn't
>exist"
>
Peter,
Just to clarify, because in a previous email you
At 09:41 21/03/01 +1200, Christopher Sawtell wrote:
>Just that it might be a good idea to incorporate the version / release
>details in some way so that when somebody on the list is squeaking about
>an error message it is obvious to the helper that the advice needed is to
>upgrade from the Cre
At 17:35 20/03/01 +0100, Peter Eisentraut wrote:
>Philip Warner writes:
>
>> elog(CACHELOOKUPFAIL, cacheItemThatFailed);
>
>The disadvantage of this approach, which I tried to explain in a previous
>message, is that we might want to have different wordings for different
>occurences of the same
On Wed, Mar 21, 2001 at 09:41:44AM +1200, Christopher Sawtell wrote:
> On Tue, 20 Mar 2001 10:56, you wrote:
>
> Just that it might be a good idea to incorporate the version / release
> details in some way so that when somebody on the list is squeaking about
> an error message it is obvious to
On Tue, 20 Mar 2001 10:56, you wrote:
> I've looked at the elog calls in the source, about 1700 in total (only
[ ... ]
> So we need some good error numbering scheme. Any ideas?
Just that it might be a good idea to incorporate the version / release
details in some way so that when somebody on
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> PGELOG(ERROR, PGSQLSTATE_TYPE, ("type %s cannot be created because it already
>exists", ...))
> put varargs into parentheses to avoid need for ... macros see Tom's proposal
I'd be inclined to make it
PGELOG((ERROR, PGSQLSTATE_TYPE, "type %s
> #define PGERR_TYPE 1854
#define PGSQLSTATE_TYPE "S0021"// char(5) SQLSTATE
The standard calls this error variable SQLSTATE
(look up in ESQL standard)
first 2 chars are class next 3 are subclass
"0" is e.g. Success
"02000" is Data not found
"U0xxx" user defined routine error xxx
Philip Warner writes:
> elog(CACHELOOKUPFAIL, cacheItemThatFailed);
The disadvantage of this approach, which I tried to explain in a previous
message, is that we might want to have different wordings for different
occurences of the same class of error.
Additionally, the whole idea behind ha
Philip Warner <[EMAIL PROTECTED]> writes:
> I also think it's important that we get the source file and line number
> somewhere in the message, and if we have these, we may not need the
> subsystem.
I agree that the subsystem concept is not necessary, except possibly as
a means of avoiding collis
At 23:56 19/03/01 +0100, Peter Eisentraut wrote:
>
>Essentially, I envision making up a new function, say "elogc", which has
>
>elogc(, [,?] , message...)
>
>where the code is some macro, the expansion of which is to be determined.
>A call to "elogc" would also require a formalized message wor
I've looked at the elog calls in the source, about 1700 in total (only
elog(ERROR)). If we mapped these to the SQL error codes then we'd have
about two dozen calls with an assigned code and the rest being "other".
The way I estimate it (I didn't really look at *each* call, of course) is
that abou
18 matches
Mail list logo
