On Fri, Jan 7, 2011 at 11:41 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Jan 7, 2011 at 8:20 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Between >>> amclusterable, amsearchnulls, and amoptionalkey, I believe that we have >>> quite enough flags already to cover what anything else actually >>> needs-to-know about the AM's behavior. > >> I've pretty much come to the conclusion that pg_am is much better at >> providing the illusion of abstraction than it is at providing actual >> abstraction. IIUC, the chances that a third-party AM would need to >> patch core are nearly 100% anyway, so I'm not inclined to spend much >> mental energy trying to figure out what flags it might hypothetically >> need. > > Well, I'll grant that allowing loadable modules to emit and replay WAL > records is an unsolved problem, but the existence of that problem > doesn't mean that we should entirely give up on keeping AMs modular. > I believe that they *are* pretty modular except for that one issue.
I'm not in a hurry to chuck the current system completely, but it strikes me that the planner basically has to know everything about what the AMs can do. I agree there's some value in encapsulating that behind Booleans, but adding a new AM, or a new feature to an existing AM, can be expected to result in regular rearrangements of those Booleans. So it seems a bit porous. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
