On Fri, Mar 2, 2012 at 1:50 PM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers