Re: Add pg_file_sync() to adminpack

Поиск
Список
Период
Сортировка
От Atsushi Torikoshi
Тема Re: Add pg_file_sync() to adminpack
Дата
Msg-id CACZ0uYGAkKeA-tsX82Ypuu1HkWem8=VeBpK0XNOD51ackKD1+w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Add pg_file_sync() to adminpack  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: Add pg_file_sync() to adminpack
Re: Add pg_file_sync() to adminpack
Список pgsql-hackers
Hello,

> On Sut, Jan 11, 2020 at  2:12 Fujii Masao <masao.fujii@gmail.com>:
> I'm not sure if returning false with WARNING only in some error cases
> is really good idea or not. At least for me, it's more intuitive to
> return true on success and emit an ERROR otherwise. I'd like to hear
> more opinions about this.

+1.
As a user, I expect these adminpack functions to do similar behaviors
to the corresponding system calls.
System calls for flushing data to disk(fsync on Linux and FlushFileBuffers
 on Windows) return different codes on success and failure, and when it
fails we can get error messages. So it seems straightforward for me to
 'return true on success and emit an ERROR otherwise'.


> > On Thu, Jan 9, 2020 at 10:39 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
> > >
> > > I think that pg_write_server_files should be allowed to call that
> > > function by default.
> >
> > But pg_write_server_files users are not allowed to execute
> > other functions like pg_file_write() by default. So doing that
> > change only for pg_file_sync() looks strange to me.

> Ah indeed.  I'm wondering if that's an oversight of the original
> default role patch or voluntary.

It's not directly related to the patch, but as far as I read the
manual below, I expected pg_write_server_files users could execute
 adminpack functions.

  | Table 21.1 Default Roles
  | pg_write_server_files: Allow writing to files in any location the database can access on the server with COPY and other file-access functions.


--
Atsushi Torikoshi

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Daniel Verite"
Дата:
Сообщение: Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Unicode escapes with any backend encoding