Re: libpgport vs libpgcommon

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.

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

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. ;-)

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(dot)GF4933(at)eldon(dot)alvh(dot)no-ip(dot)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

On Fri, 2013-10-18 at 16:00 -0300, Alvaro Herrera wrote:
> Please have a look at my patch at
> 20130827215416(dot)GF4933(at)eldon(dot)alvh(dot)no-ip(dot)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.