On 22 September 2016 at 20:02, Yury Zhuravlev <[email protected]> wrote: > On четверг, 15 сентября 2016 г. 19:09:16 MSK, Tom Lane wrote: >> >> Robert Haas <[email protected]> writes: >>> >>> On Thu, Sep 15, 2016 at 11:01 AM, Anastasia Lubennikova >>> <[email protected]> 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 ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
