Re: [PATCH] cleanup hashindex for pg_migrator hashindex compat mode (for 8.4)

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kenneth Marshall <ktm(at)rice(dot)edu>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] cleanup hashindex for pg_migrator hashindex compat mode (for 8.4)
Date: 2009-05-26 13:44:34
Message-ID: 1243345474.1296.52.camel@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Tom Lane píše v po 25. 05. 2009 v 13:07 -0400:
> Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
> > Tom Lane píše v ne 24. 05. 2009 v 18:46 -0400:
> >> In any case, the barriers to implementing 8.3-style hash indexes in 8.4
> >> are pretty huge: you'd need to duplicate not only the hash AM code, but
> >> also all the hash functions, and therefore all of the hash pg_amop and
> >> pg_amproc entries.
>
> > I'm not sure if I need duplicate functions. Generally yes but It seems
> > to me that hash index does not changed functions behavior and they could
> > be shared at this moment.
>
> No, the behavior of the hash functions themselves changed during 8.4.
> Twice, even:

hmm, I'm missed it. :(

> So as far as I can see, you need completely separate copies of both
> hash_any() and the SQL-level functions that call it. I'm not really
> seeing that the proposed refactoring makes this any easier. You might
> as well just copy-and-paste all that old code into a separate set of
> files, and not worry about what is in access/hash.h.

Yeah, in this case everything have to be duplicated which is not big
deal in comparison to do same amount of work for GIN. Then I can start
with GIN.

The advantage of refactoring is then only nicer code.

thanks Zdenek

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-05-26 13:47:44 Re: problem with plural-forms
Previous Message Tom Lane 2009-05-26 13:39:54 Re: generic options for explain