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
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
15 matches
Mail list logo
