Thread: libpgport vs libpgcommon

libpgport vs libpgcommon

From
Peter Eisentraut
Date:
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.




Re: libpgport vs libpgcommon

From
Noah Misch
Date:
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



Re: libpgport vs libpgcommon

From
Peter Eisentraut
Date:
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. ;-)




Re: libpgport vs libpgcommon

From
Alvaro Herrera
Date:
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



Re: libpgport vs libpgcommon

From
Peter Eisentraut
Date:
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.