From: | Atsushi Torikoshi <atorik(at)gmail(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Arthur Zakirov <zaartur(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add pg_file_sync() to adminpack |
Date: | 2020-01-14 15:08:06 |
Message-ID: | CACZ0uYGAkKeA-tsX82Ypuu1HkWem8=VeBpK0XNOD51ackKD1+w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
> On Sut, Jan 11, 2020 at 2:12 Fujii Masao <masao(dot)fujii(at)gmail(dot)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(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-01-14 15:10:36 | Re: Unicode escapes with any backend encoding |
Previous Message | Daniel Verite | 2020-01-14 14:53:37 | Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR |