On Mon, 2008-09-15 at 08:52 -0400, Tom Lane wrote: > Gregory Stark <[EMAIL PROTECTED]> writes: > > Simon Riggs <[EMAIL PROTECTED]> writes: > >> Indexes have always been able to be added dynamically. Now they can be > >> recovered correctly as well. > > > Hm, so currently if you want to add a new indexam you can't just insert into > > pg_am and make them recoverable. You basically have to build in your new > > index > > access method into Postgres with the new rmgr. That is annoying and a > > problem > > worth tackling. > > I concur with Heikki that that's not exactly a compelling use-case. > I've never heard of anyone building a non-core index AM at all; much > less trying to use it in a production context. Given the obvious > potential for version-mismatch-type problems, it's hard to believe > that anyone ever would try.
The lack of a chicken is not an argument against the use case for an egg. But in any case, Bizgres was exactly this case, so they already did. We just forced the authors to produce a code fork to do it, confusing people rather than attracting people to Postgres. We have plugin APIs with possible version mismatches in other contexts, but I don't see us doing anything about that. In the context of WAL, the basic WAL format has not changed in about 6 releases, so its been one of the most stable file formats. Certain message types have changed, but messages are all independent across rmgrs, so insulated from change. The version mismatch idea presumes that a code author would structure their code in two pieces: one to generate the WAL and one to read it. Seems much more likely to me that authors would have one module containing both as a way of avoiding the problem altogether. So I'm not sure what to check, and against what? When people do write useful plugins in the future they will be potentially usable with any server at 8.4 or above. If we had had this feature a few releases ago, we could have made GIN available to earlier releases, for example. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
