On Tue, Apr 3, 2012 at 11:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Apr 3, 2012 at 10:40 AM, Joachim Wieland <joe@mcknight.de> wrote:
>>> I completely agree. Assertions helped a lot dealing with concurrent
>>> code. How do you want to tackle this for now? Want me to create a
>>> separate header pg_assert.h as part of my patch? Or is it okay to
>>> factor it out later and include it from the general header then?
>
>> I'll just go do it, barring objections.
>
> If the necessary support code isn't going to be available *everywhere*,
> it should not be in postgres.h. So I did not care for your proposal to
> put it in dumputils.
Err... I didn't suggest putting it in postgres.h. I suggested taking
it OUT of postgres.h and putting it in a separate header file.
> Possibly we could move assert.c into src/port/ and make it part of
> libpgport?
The trouble is that it calls write_stderr(), which has a non-trivial
implementation on Windows that I don't believe will be suitable for
front-end code. If we can find a reasonable way to work around that
issue then I think that would work. We might also want to rename
ExceptionalCondition() to pg_exceptional_condition or something like
that if we're going to include it in libpgport.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
