libpgport vs libpgcommon

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 10/16/13 10:10 PM, Noah Misch wrote:

dirmod.c perhaps deserves a
split into libpgcommon parts (e.g. pgfnames()) and libpgport parts
(e.g. pgrename()).

I have also come to this realization. I propose to move pgfnames to
src/common/pgfnames.c.

Hopefully there's not much more.

I have also come to this realization. ;-)

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Peter Eisentraut wrote:

On 10/16/13 10:10 PM, Noah Misch wrote:

dirmod.c perhaps deserves a
split into libpgcommon parts (e.g. pgfnames()) and libpgport parts
(e.g. pgrename()).

I have also come to this realization. I propose to move pgfnames to
src/common/pgfnames.c.

Please have a look at my patch at
20130827215416.GF4933@eldon.alvh.no-ip.org particularly the checkdir.c
file. Perhaps we'd like to put both these routines (which are related
to directories) in a single file (directory.c?). In that case I would
suggest putting your new routine in that file, and we'd add the checkdir
stuff in there eventually.

I don't necessarily object to pgfnames.c in any case, if that's thought
to be cleaner.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, 2013-10-18 at 16:00 -0300, Alvaro Herrera wrote:

Please have a look at my patch at
20130827215416.GF4933@eldon.alvh.no-ip.org particularly the checkdir.c
file. Perhaps we'd like to put both these routines (which are related
to directories) in a single file (directory.c?). In that case I would
suggest putting your new routine in that file, and we'd add the
checkdir
stuff in there eventually.

I think smaller files are better, especially for a static library.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers