From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: equal() perf tweak |
Date: | 2003-11-05 18:22:35 |
Message-ID: | 3623.1068056555@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
I said:
> No, lfirst and friends will need to apply to ListCells not to Lists,
> else the coding of foreach loops will break everywhere. I think there
> are many more places that will want lfirst to apply to a ListCell than
> will want it to apply to a raw List.
On the other hand, we will need to touch every foreach loop anyway to
update the datatype of the iteration variable. I can see merit in the
idea of *deliberately* breaking any un-updated code by means of removing
the lfirst and lnext macros completely. If we go that path, we could
use names like
nextcell(cl) replaces lnext()
cellvalue(cl) replaces lfirst()
cellvaluei(cl) replaces lfirsti()
cellvalueo(cl) replaces lfirsto()
plus invent names like ListFirst(), ListSecond(), etc for the cases
where you really are fetching the n'th element of a List rather than
the contents of the current ListCell.
I'm not wedded to these particular naming suggestions, just thinking
that maybe backwards-compatibility of the macro names isn't such a hot
idea after all. What do you think?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-11-05 18:28:43 | Re: Erroneous PPC spinlock code |
Previous Message | Peter Eisentraut | 2003-11-05 18:22:04 | Open Issues for 7.4 |
From | Date | Subject | |
---|---|---|---|
Next Message | Gaetano Mendola | 2003-11-06 00:26:21 | Re: equal() perf tweak |
Previous Message | Tom Lane | 2003-11-05 17:08:14 | Re: equal() perf tweak |