Re: Inline Extension - Mailing list pgsql-hackers

On Sun, Jan 22, 2012 at 8:42 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Sun, Jan 22, 2012 at 3:20 PM, Daniel Farina <daniel@heroku.com> wrote:
>> A few anecdotes does not constitute evidence, but it does look like
>> some people pay attention to any additional versioning foothold they
>> can get.
>
> Sure, but just because some people do it doesn't make it a good idea.

True, I did not mean to suggest that this is clearly the best
mechanism, only to express support for the general idea that people
are appreciative and willing to experiment with any way to make
version management better, and people who use those features are
*probably* going to try to use them correctly.  It's up to us to make
the right-thing easy, too, otherwise I fear we will see too many lousy
version numbers creeping about in the wild.

> Dimitri's proposal was to neuter the pg_dump
> support that is the raison d'être of the extension mechanism.  That's
> clearly necessary if you don't want to end up with an unreloadable
> database, but it begs the question (which no one's really answered
> AFAICT) of what good the extension mechanism is without that feature.

Oh, no, non-reloadability is a really bad thing -- I'd say a pretty
bad deal-breaker -- but as Tom wrote, it does seem like it should
somehow be a tractable problem.

Is it such a bad idea to store the literal text of the extension's
pieces (control file and corresponding SQL program) in catalogs?  I'm
not sure if I understand why everyone is so interested in a special
interaction with the file system in some way.  By the same token,
extensions can be dumped in the literal syntax -- even the ones that
were installed from a file.

> There are certainly easier ways to remember a version number than
> building support for it into core.  If people create their own
> versioning mechanisms, they can create something which is tailor-made
> for their particular requirements, rather than relying on decisions
> which we made in core that may or may not be right for them (e.g. the
> lack of version ordering, or even that we have versions rather than
> some more general type of control table).

I understand the desire to avoid investing in something that is not
what people want.  However, in the interest of scoping the discussion
to the inline extension support, I can't seem to understand the
objection to supporting what is basically a different transport for
precisely the same semantic operation as having to ssh into a machine
and untar some files, except available without the bizarre
side-channel of ssh and fie system mangling when one is loading
trustable operators, itself a raft of usability issues if one wishes
to enable more software reuse.

--
fdr