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
