From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: libpgport vs libpgcommon |
Date: | 2013-10-17 02:10:44 |
Message-ID: | 20131017021044.GA335400@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2013-10-17 02:23:49 | Re: FDW API / flow charts for the docs? |
Previous Message | Peter Eisentraut | 2013-10-17 02:01:30 | Re: LDAP: bugfix and deprecated OpenLDAP API |