> > > Should the pg_log_ prefix strictly refer to functions that write to
> > > logs?
> > >
> >
> > I don't know how strict we should be about this,
>
> I don't know as well and specially given that:
>
> - the snapshot is logged to the log file (if log level <= DEBUG2)
But unlike pg_log_backend_memory_contexts, the primary purpose
of this function is not to write at the LOG message level.
> - that name also makes sense from an API point of view as it calls "LogStandbySnapshot"
I don't really see the correlation between the user facing pg_log_
prefix and the Log prefixed
functions that write to wal.
But this goes back to the main point of should pg_log_ be specific to
functions that
write to the server logs only. I am making the argument that we
should. We have a precedent
with pg_stat_ being the prefix for any function related to the cumulative stats.
I think it keeps things nicely organized and just overall good code
hygiene, but also not sure
how we can even enforce such naming conventions.
> > The other option could be pg_create_standby_snapshot(), which would be
> > similar to the existing function pg_create_restore_point(). I think we
> > need to think about backward compatibility if we agree with moving in
> > this direction.
>
> +1
This is slightly better. pg_create_restore_point also writes to wal and _create_
has a more generic meaning.
--
Sami Imseih
Amazon Web Services (AWS)
