On Fri, Jan 7, 2011 at 8:20 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > David Fetter <da...@fetter.org> writes: >> On Fri, Jan 07, 2011 at 08:08:38PM -0500, Tom Lane wrote: >>> Anyone against simplifying matters by getting rid of >>> pg_am.amindexnulls? > >> I guess the only potential use for it would be for some kind of am >> that *couldn't* index nulls out of the gate. Might their be such AMs >> on the horizon? > > Well, there are AMs around already that can't index nulls: hash is one, > and GIN was one until an hour ago. The question though is whether > anything outside the AM needs to know about that behavior. 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. In other words, go nuts. -- 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
