On Fri, Mar 2, 2012 at 1:50 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> But is it unsurmountable? -- dlsym returns a function pointer, and one
>> would build up the operator table for the version of the extension at
>> hand, so one might have ltree "version 1.01" and ltree "version 2.3"
>> fields in the same database.
>
> That might be possible, but it seems largely unrelated to the topic of
> this thread, unless I am missing something.
It might be, and might not be, because if we start getting into where
to put shared objects for functionality linked to the database (rather
just letting the dynamic linker do "whatever") it could crash head-on
into data field versioning and replica issues. If someone thinks
about it for a few minutes and says "nope, orthogonal," I'm without
objection, but I did want to raise this spectre to other minds because
it seems to be on the edge of that maelstrom.
I also look at the inability for pg_upgrade to help when certain
contribs are used between versions and can only say "phew, I'm glad
that doesn't affect most people" (a sad flip side: people aren't using
contribs and database extension as much as I like, but things are
moving towards more of that and not less) because then the expected
duration of the upgrade process becomes a very ugly compatibility
matrix that nobody wants to see...somewhat dissatisfying for a service
provider. Yet, formats can and will change requiring a lot of
gradual I/O, and a version byte is not always practical, so the best
option I can think of is to support multiple versions of formats,
operators and types at the same time, and then gradually rewrite
things.
I'm not intending to open discussion about any of that right now
(unless someone else is interested and wants to start a new thread),
but I wanted to provide insight as to to why I'm especially
preoccupied about this.
--
fdr
