From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Peter Geoghegan <peter(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: enhanced error fields |
Date: | 2012-08-20 13:09:38 |
Message-ID: | CAFj8pRAeKa2zFk4g6y2PRfSfeLEQUc5M1UUj2pLgEKs_oK=_9Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello
here is updated patch - merge comments, docs, formatting, some
identifiers from Peter Geoghegan's patch
Regards
Pavel
2012/7/18 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
> 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-08-20.diff | application/octet-stream | 36.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-08-20 14:04:52 | Re: New WAL code dumps core trivially on replay of bad data |
Previous Message | Daniel Bausch | 2012-08-20 10:33:19 | Re: State of the on-disk bitmap index |