Re: equal() perf tweak

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

In response to

Browse pgsql-hackers by date

  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

Browse pgsql-patches by date

  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