Re: libpgport vs libpgcommon
От | Noah Misch |
---|---|
Тема | Re: libpgport vs libpgcommon |
Дата | |
Msg-id | 20131017021044.GA335400@tornado.leadboat.com обсуждение исходный текст |
Ответ на | libpgport vs libpgcommon (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: libpgport vs libpgcommon
|
Список | 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
В списке pgsql-hackers по дате отправления: