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
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 |