Re: PATCH: CreateComments: use explicit indexing for ``values'' - Mailing list pgsql-hackers

From richhguard-monotone@yahoo.co.uk
Subject Re: PATCH: CreateComments: use explicit indexing for ``values''
Date
Msg-id 87573.95481.qm@web86702.mail.ird.yahoo.com
Whole thread Raw
In response to PATCH: CreateComments: use explicit indexing for ``values''  (richhguard-monotone@yahoo.co.uk)
Responses Re: PATCH: CreateComments: use explicit indexing for ``values''
Re: PATCH: CreateComments: use explicit indexing for ``values''
List pgsql-hackers
Apologies - I meant to CC in the list but forgot.

I have gone through and changed all the related functions except ``update_attstats''.

Do you have any advice of how to handle the inner loops, such as those initializing ``stakindN''. The entries before
canbe handled just like in this patch, by using the symbolic constants. 

Again, this is based on master and all existing tests pass.

Regards
Richard

--- On Mon, 13/6/11, richhguard-monotone@yahoo.co.uk <richhguard-monotone@yahoo.co.uk> wrote:

> From: richhguard-monotone@yahoo.co.uk <richhguard-monotone@yahoo.co.uk>
> Subject: Re: [HACKERS] PATCH: CreateComments: use explicit indexing for ``values''
> To: "Tom Lane" <tgl@sss.pgh.pa.us>
> Date: Monday, 13 June, 2011, 21:08
> I have gone through and changed all
> the related functions except ``update_attstats''.
>
> Do you have any advice of how to handle the inner loops,
> such as those initializing ``stakindN''. The entries before
> can be handled just like in this patch, by using the
> symbolic constants.
>
> Again, this is based on master and all existing tests
> pass.
>
> Regards
> Richard
>
> --- On Mon, 13/6/11, Tom Lane <tgl@sss.pgh.pa.us>
> wrote:
>
> > From: Tom Lane <tgl@sss.pgh.pa.us>
> > Subject: Re: [HACKERS] PATCH: CreateComments: use
> explicit indexing for ``values''
> > To: richhguard-monotone@yahoo.co.uk
> > Cc: "Robert Haas" <robertmhaas@gmail.com>,
> pgsql-hackers@postgreSQL.org
> > Date: Monday, 13 June, 2011, 16:09
> > 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
> >


pgsql-hackers by date:

Previous
From: Jeff Shanab
Date:
Subject: Libpq in VS 2010
Next
From: Shigeru Hanada
Date:
Subject: Re: FOREIGN TABLE doc fix