| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
| Cc: | Kenneth Marshall <ktm(at)rice(dot)edu>, Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>, "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-25 13:59:14 |
| Message-ID: | 2535.1243259954@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Dimitri Fontaine <dfontaine(at)hi-media(dot)com> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> The rearrangement might be marginally nicer from a code beautification
>> point of view --- right now we're a bit inconsistent about whether
>> datatype-specific hash functions live in hashfunc.c or in the datatype's
>> utils/adt/ file. But I'm not sure that removing hashfunc.c altogether is
>> an appropriate solution to that, not least because of the loss of CVS
>> history for the functions. I'd be inclined to leave the core hash_any()
>> code where it is, if not all of these functions altogether.
> I guess someone has to talk about it: git will follow the code even when
> the file hosting it changes.
That might possibly be relevant a year from now; it is 100% irrelevant
to a change being proposed for 8.4.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2009-05-25 14:16:34 | Re: Doubt |
| Previous Message | Dimitri Fontaine | 2009-05-25 13:51:06 | Re: Feedback on writing extensible modules |