From: | Yury Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru> |
---|---|
To: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: File system operations. |
Date: | 2016-09-22 12:02:55 |
Message-ID: | 4f6c2489-02ef-4efb-8525-864f50cf55ab@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On четверг, 15 сентября 2016 г. 19:09:16 MSK, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Thu, Sep 15, 2016 at 11:01 AM, Anastasia Lubennikova
>> <a(dot)lubennikova(at)postgrespro(dot)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.
--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2016-09-22 12:36:42 | Re: Parallel sec scan in plpgsql |
Previous Message | Kuntal Ghosh | 2016-09-22 11:07:53 | Re: pgbench - compute & show latency consistently |