Re: where should I stick that backup? - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: where should I stick that backup?
Date
Msg-id 20200410154839.GA24988@momjian.us
Whole thread Raw
In response to Re: where should I stick that backup?  (Stephen Frost <sfrost@snowman.net>)
Responses Re: where should I stick that backup?  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Fri, Apr 10, 2020 at 10:54:10AM -0400, Stephen Frost wrote:
> Greetings,
> 
> * Robert Haas (robertmhaas@gmail.com) wrote:
> > On Thu, Apr 9, 2020 at 6:44 PM Bruce Momjian <bruce@momjian.us> wrote:
> > > Good point, but if there are multiple APIs, it makes shell script
> > > flexibility even more useful.
> > 
> > This is really the key point for me. There are so many existing tools
> > that store a file someplace that we really can't ever hope to support
> > them all in core, or even to have well-written extensions that support
> > them all available on PGXN or wherever. We need to integrate with the
> > tools that other people have created, not try to reinvent them all in
> > PostgreSQL.
> 
> So, this goes to what I was just mentioning to Bruce independently- you
> could have made the same argument about FDWs, but it just doesn't
> actually hold any water.  Sure, some of the FDWs aren't great, but
> there's certainly no shortage of them, and the ones that are
> particularly important (like postgres_fdw) are well written and in core.

No, no one made that argument.  It isn't clear how a shell script API
would map to relational database queries.  The point is how well the
APIs match, and then if they are close, does it give us the flexibility
we need.  You can't just look at flexibility without an API match.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] advanced partition matching algorithm for partition-wise join
Next
From: Ashutosh Bapat
Date:
Subject: Re: [HACKERS] advanced partition matching algorithm forpartition-wise join