Re: enhanced error fields

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: enhanced error fields
Дата
Msg-id CAFj8pRA2fJ1D6X_eLnkpByM_=0GJ6H9tdo1cXWoHBzwTBMe+xg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: enhanced error fields  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: enhanced error fields  (Peter Geoghegan <peter@2ndquadrant.com>)
Re: enhanced error fields  (Pavel Stehule <pavel.stehule@gmail.com>)
Список 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@sss.pgh.pa.us>:
> Alvaro Herrera <alvherre@commandprompt.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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Fix mapping of PostgreSQL encodings to Python encodings.
Следующее
От: Andrew Dunstan
Дата:
Сообщение: row literal problem