From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Fetter <david(at)fetter(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Remove pg_am.amindexnulls? |
Date: | 2011-01-08 03:09:26 |
Message-ID: | AANLkTi=GAd605q-O5jTqpeMQ6fXJxBYWQUW7B8fG=cdx@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 7, 2011 at 8:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> David Fetter <david(at)fetter(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2011-01-08 03:37:31 | pg_upgrade map struct cleanup |
Previous Message | Bruce Momjian | 2011-01-08 03:01:17 | Re: Fix for pg_upgrade migrating pg_largeobject_metadata |