Re: [PATCH] cleanup hashindex for pg_migrator hashindex compat mode (for 8.4) - Mailing list pgsql-hackers

From Zdenek Kotala
Subject Re: [PATCH] cleanup hashindex for pg_migrator hashindex compat mode (for 8.4)
Date
Msg-id 1243345474.1296.52.camel@localhost
Whole thread Raw
In response to Re: [PATCH] cleanup hashindex for pg_migrator hashindex compat mode (for 8.4)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane píše v po 25. 05. 2009 v 13:07 -0400:
> Zdenek Kotala <Zdenek.Kotala@Sun.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




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: generic options for explain
Next
From: Tom Lane
Date:
Subject: Re: problem with plural-forms