Re: libpgport vs libpgcommon - Mailing list pgsql-hackers

From Noah Misch
Subject Re: libpgport vs libpgcommon
Date
Msg-id 20131017021044.GA335400@tornado.leadboat.com
Whole thread Raw
In response to libpgport vs libpgcommon  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: libpgport vs libpgcommon  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On Wed, Oct 16, 2013 at 09:41:20PM -0400, Peter Eisentraut wrote:
> I wonder whether it was ever consciously decided what the dependency
> relationship between libpgport and libpgcommon would be.  When I added
> asprintf(), I had intuitively figured that libpgport would be the lower
> layer, and so psprintf() in libpgcommon depends on vasprintf() in
> libpgport.  I still think that is sound.  But working through the
> buildfarm issues now it turns out that wait_result_to_str() in libpgport
> depends on pstrdup() in libpgcommon.  That doesn't seem ideal.  I think
> in this case we could move wait_error.c to libpgcommon.  But I would
> like to know what the consensus on the overall setup is.

Interesting.  I, too, would have figured that libpgport is lower-level,
because any higher-level library might need the libc functions it replaces.
Moving wait_error.c to libpgcommon makes sense.  dirmod.c perhaps deserves a
split into libpgcommon parts (e.g. pgfnames()) and libpgport parts
(e.g. pgrename()).  Hopefully there's not much more.

Thanks,
nm

-- 
Noah Misch
EnterpriseDB                                 http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: LDAP: bugfix and deprecated OpenLDAP API
Next
From: Alvaro Herrera
Date:
Subject: Re: FDW API / flow charts for the docs?