Horton

Re: enhanced error fields

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Peter Geoghegan <peter@2ndquadrant.com>, Pavel Stehule <pavel.stehule@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2012-07-10T22:39:07Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Create a "sort support" interface API for faster sorting.

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