Re: [HACKERS] libpgport vs libpgcommon
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
Re: [HACKERS] libpgport vs libpgcommon
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.gf4...@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 Herrerahttp://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
Re: [HACKERS] libpgport vs libpgcommon
On Fri, 2013-10-18 at 16:00 -0300, Alvaro Herrera wrote: Please have a look at my patch at 20130827215416.gf4...@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
[HACKERS] 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 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
