Re: Re: [COMMITTERS] pgsql: Send new protocol keepalive messages to standby servers.

Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> I thought I already pointed that out, but: we have *extensions*.  What
>> we don't have is a convenient method of dealing with functions that need
>> to be migrated across extensions, or from an extension to core, between
>> one major release and the next.  It would clearly be nice to have that
>> someday, but we don't have it now.  Designing on the assumption that 9.3

> Well, my patch for 9.2 called "Finer Extension Dependencies" was all
> about supporting that. The idea is to be able to name a set of functions
> (or other objects) then setup a dependency graph towards that arbitrary
> name. Then it's possible to migrate that named set of objects from an
> extension to another one, and it's possible for core to publish a list
> of provided names of set of objects provided.

Well, TBH I didn't think that concept was a useful solution for this at
all.  I can't imagine that we would define "features" at a sufficiently
fine granularity, or with enough advance foresight, to solve the sort of
problem that's being faced here.  How would you deal with the need for,
say, some of contrib/xml2's functions to get migrated to core in 9.4 or
so?  When you didn't know that would happen, much less exactly which
functions, when 9.3 came out?  AFAICS the only way that "features" could
fix this would be if we always created a feature for every exposed
function, which is unmanageable.

> The only missing part in the patch is allowing for the "core" to declare
> a set of set of objects (a set of features in its current terminology)
> that it brings on the table. Such a list already exists though, and is
> using the same terminology as in my patch:
>   http://www.postgresql.org/docs/9.2/static/features-sql-standard.html
> We wouldn't only publish the standard compliant feature list with such a
> mechanism though or it would be quite useless for our operations here.

AFAICS, the SQL-standard features list is just about entirely irrelevant
to this discussion.  How often is it going to happen that we implement a
standard feature in a contrib module before migrating it into core?
I think almost every case in which we'll face this problem will involve
a PG-specific feature not mentioned in the SQL feature taxonomy.  The
case at hand (some proposed new functions for managing replication)
certainly isn't going to be found there.

And, quite aside from whether we could invent feature names that match
what we want to move from contrib to core, exactly how would having a
feature name help?  The problem we're actually facing is getting
pg_upgrade to not dump particular functions when it's doing a
binary-upgrade dump of an extension.  Maybe I've forgotten, but I do not
recall any exposed connection between feature names and particular SQL
objects in your proposal.
        regards, tom lane