Re: [PATCH] Store Extension Options

On Thu, Mar 13, 2014 at 11:37 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> I seriously doubt that's going to work nicely. Now you've implicitly
>> introduced a dependency from every object that has a label to the
>> label provider. pg_dump is going to have to restore the validator
>> function before it restores anything that has a label, and before that
>> it's going to have to restore the languages used to create those
>> validator functions, and those languages might themselves be labeled,
>> either by that provider or by other providers.
>
> Aren't pretty much all of those problems already solved because already
> need to be able to order all this to dump the extension for a datatype
> before the relation with a column of that type?

Well, there's dependency tracking in general. But security label
providers don't exist as SQL objects today, so they don't participate
in it. You'd need to make them dumpable objects and then add
dependencies in pg_(sh)depend and then figure out how to break cycles.
We could do that, but I'm not finding it very compelling.

>> Perhaps you could untangle that mess, but I'm disinclined to try
>> because I can't see what real problem we're solving here. Extension
>> that just provide particular functions or datatypes can be loaded on
>> demand, but those that change underlying system behavior need to be
>> loaded by the postmaster, or at least at backend startup.
>
> Why is adding an annotation to a table "changing the underlying system
> behaviour"? There might be cases where it is, and those can easily
> require having been loaded via s_p_l.

I guess that's true.

>> There are five contrib modules that define
>> custom variables: auth_delay, auto_explain, pg_stat_statements,
>> sepgsql, and worker_spi. auth_delay, worker_spi and
>> pg_stat_statements have to be loaded at postmaster startup time, and
>> you have to decide whether you want sepgsql at *initdb* time.
>
> You forgot at least plpgsql. Which is already a good showcase why we
> want this to be per database, not per cluster, i.e. not preloaded.

OK, true.

>> Maybe there are better examples outside the
>> core distribution, but to me it's looking like the idea that you can
>> add GUCs on the fly into individual sessions is a big fizz.
>
> It seems to be on a somewhat odd warpath against against custom gucs ;)
> . I've used the capability to do so *dozens* of times. What problems
> have they actually caused?
>
> Note that postgresql.conf is parsed long before we initiate
> shared_preload_libraries et al are taking effect, so even if we'd
> require libraries to be loaded before custom GUCs can be defined, we'd
> need to create a entirely new mechanism of loading libraries for
> it. With a very odd circularity, because to parse postgresql.conf you'd
> need to have it parsed to load the libraries.

Yes, that's part of the problem there.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company