On Fri, Nov 08, 2019 at 11:12:08PM +0900, Simon Riggs wrote:
>On Thu, 7 Nov 2019 at 10:24, Bruce Momjian <bruce@momjian.us> wrote:
>
>
>> What is the value of a shared library over a shell command? We had
>> this discussion in relation to archive_command years ago, and decided
>> on a shell command as the best API.
>>
>
>I don't recall such a discussion, but I can give perspective:
>
>* shell command offered the widest and simplest API for integration,
>which was the most important consideration for a backup API. That
>choice caused difficulty with the need to pass information to the
>external command, e.g. %f %p
>
It's not clear to me why simple API for integration would be less
valuable for this feature. Also, I'm sure passing data to/from shell
command may be tricky, but presumably we have figured how to do that.
>* shared library is more appropriate for a security-related module, so
>users can't see how it is configured, as well as being more
>tightly integrated so it can be better tailored to various uses
>
I don't follow. Why would there be a significant difference between a
shell command/script and shared library in this respect? If you don't
want the users to see the config, just store it in a separate file and
it's about the same as storing it in the .so library.
Is there something that can be done with a .so library but can't be done
with a shell command (which may just call a binary, with all the config
included, making it equal to the .so solution)?
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
