On Tue, Apr 3, 2012 at 11:38 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Tue, Apr 3, 2012 at 10:40 AM, Joachim Wieland <j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
