Re: PATCH: CreateComments: use explicit indexing for ``values''

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: richhguard-monotone(at)yahoo(dot)co(dot)uk
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: PATCH: CreateComments: use explicit indexing for ``values''
Date: 2011-06-13 15:09:36
Message-ID: 18422.1307977776@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
>> Historically this i++ approach has been used in a lot of places that
>> fill in system catalog tuples. We've fixed some of them over
>> time, but I doubt this is the only one remaining. If we're going
>> to try to remove it here, maybe we ought to try to fix them all
>> rather than just this one.

A quick grep reveals that the places that still do it that way are

OperatorShellMake
OperatorCreate
TypeShellMake
TypeCreate
update_attstats (though this one might be hard to improve)
CreateComments
CreateSharedComments
InsertRule

Of these, all but the two in comment.c follow the convention of
mentioning the assigned-to column in a comment, so that the code
is at least somewhat greppable. So those two definitely need
improvement, but should we consider changing the others while at it?

BTW, there are some contrib modules with functions-returning-record that
fill in result tuples this way as well. But we don't have symbolic
constants for the column numbers there, and it's probably not worth
introducing such.

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2011-06-13 15:16:06 Re: On-the-fly index tuple deletion vs. hot_standby
Previous Message Robert Haas 2011-06-13 15:06:46 Re: lazy vxid locks, v1