On Mon, Jan 31, 2022 at 4:40 PM Greg Stark <st...@mit.edu> wrote: > So I looked at this patch and I have the same basic question as Bruce. > Do we really want to expose every binary tool associated with Postgres > as an extension? Obviously this is tempting for cloud provider users > which is not an unreasonable argument. But it does have consequences. > > 1) Some things like pg_waldump are running code that is not normally > under user control. This could have security issues or reliability > issues.
For what it's worth, I am generally in favor of having something like this in PostgreSQL. I think it's wrong of us to continue assuming that everyone has command-line access. Even when that's true, it's not necessarily convenient. If you choose to use a relational database, you may be the sort of person who likes SQL. And if you are, you may want to have the database tell you what's going on via SQL rather than command-line tools or operating system utilities. Imagine if we didn't have pg_stat_activity and you had to get that information by running a separate binary. Would anyone like that? Why is this case any different? A few years ago we exposed data from pg_control via SQL and similar concerns were raised - but it turns out to be pretty useful. I don't know why this shouldn't be equally useful. Sure, there's some duplication in functionality, but it's not a huge maintenance burden for the project, and people (including me) like having it available. I think the same things will be true here. If decoding WAL causes security problems, that's something we better fix, because WAL is constantly decoded on standbys and via logical decoding on systems all over the place. I agree that we can't let users supply their own hand-crafted WAL records to be decoded without causing more trouble than we can handle, but if it's not safe to decode the WAL the system generated than we are in a lot of trouble already. I hasten to say that I'm not endorsing every detail or indeed any detail of the proposed patch, and some of the concerns you mention later sound well-founded to me. But I disagree with the idea that we shouldn't have both a command-line utility that roots through files on disk and an SQL interface that works with a running system. -- Robert Haas EDB: http://www.enterprisedb.com