On 22 September 2016 at 20:02, Yury Zhuravlev <u.zhurav...@postgrespro.ru> wrote: > On четверг, 15 сентября 2016 г. 19:09:16 MSK, Tom Lane wrote: >> >> Robert Haas <robertmh...@gmail.com> writes: >>> >>> On Thu, Sep 15, 2016 at 11:01 AM, Anastasia Lubennikova >>> <a.lubennik...@postgrespro.ru> wrote: >>>> >>>> What do you think about moving stuff from pg_upgrade/file.c to >>>> storage/file/ >>>> to allow reuse of this code? I think it'll be really helpful for >>>> developers >>>> of contrib modules >>>> like backup managers. >> >> >>> Well, storage/file is backend and pg_upgrade is frontend. If you want >>> to reuse the same code for both it's got to go someplace else. >> >> >> Also, to the extent that it's important to use those wrappers rather >> than libc directly, it's because the wrappers are tied into backend >> resource management and error handling conventions. I don't see how >> you convert that into code that also works in a frontend program, >> or what the point would be exactly. > > > Maybe we should towards to framework ecosystem. I mean, developers of third > party tools must use maximum same api what in backend.
Well, there's a very gradual shift in that direction with libpgcommon etc. But it's minimalist. Most of what's done in the backend makes no sense in frontend code. It'd make much more sense to adopt an existing portable runtime (nspr, apr, whatever) than write our own if we wanted to go full framework. But I don't think we're likely to. Much more likely to cause pain than prevent it, esp since we're multiprocessing and shmem based. There are a few areas we could use abstractions for though, like fork()/exec() vs CreateProcessEx(...). -- Craig Ringer 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
