Re: enhanced error fields

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Peter Geoghegan <peter(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: enhanced error fields
Date: 2012-07-18 18:13:09
Message-ID: CAFj8pRA2fJ1D6X_eLnkpByM_=0GJ6H9tdo1cXWoHBzwTBMe+xg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello

* renamed erritem to err_generic_string
* fixed CSVlog generation
* new file /utils/error/relerror.c with axillary functions -
declarations are in utils/rel.h

Regards

Pavel

2012/7/11 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> FWIW about the new include: I feel a strong dislike about the forward
>> declaration you suggest. Defining Relation in elog.h seems completely
>> out of place.
>
> Agreed. Maybe a reasonable solution is to allow some ereport helper
> functions (or, really, wrappers for the helper functions) to be declared
> someplace else than elog.h. They'd likely need to be implemented
> someplace else than elog.c, too, so this doesn't seem unreasonable.
>
> The generic helper function approach doesn't seem too unreasonable for
> this: elog.h/.c would provide something like
>
> err_generic_string(int fieldid, const char *str)
>
> and then someplace else could provide functions built on this that
> insert table/schema/column/constraint/etc names into suitable fields.
>
> regards, tom lane

Attachment Content-Type Size
eelog-2012-07-18.patch application/octet-stream 31.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2012-07-18 18:58:22 row literal problem
Previous Message Rene Romero Benavides 2012-07-18 16:20:56 Re: Where is diskchecker.pl ?