Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] other changes

From: dg(at)informix(dot)com (David Gould)
To: maillist(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian)
Cc: hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] other changes
Date: 1998-08-31 08:13:55
Message-ID: 9808310813.AA12632@hawk.oak.informix.com (view raw or flat)
Thread:
Lists: pgsql-hackers
> 
> Also, during the pgindent run, we have TypeTupleForm and
> AttributeTupleForm, while we also have Form_pg_class, etc.
> 
> Seems they should be named similar.  It will make the Developers FAQ
> item 9 easier to understand if we have uniform way to cast a HeapTuple
> pointer.
> 
> 	TypeTupleForm -> Form_pg_type
> 
> In fact the comments in pg_type.h talk about Form_pg_type, but they then
> define TypeTupleForm.
> 
> Any problems with changing this?
> 
> ---------------------------------------------------------------------------
> 
> 
> /* ----------------
>  *      Form_pg_type corresponds to a pointer to a row with
>  *      the format of pg_type relation.
>  * ----------------
>  */
> typedef TypeTupleFormData *TypeTupleForm;
> 

There is a lot of 'ObjectVerb' naming in postgres. And some the other way too.
Personally, having looked at Illustra code a few years, I am quite comfortable
with the 'TypeTupleForm' flavor and would be badly confused by 'Form_pg_type'
as I think of the result of the call as a 'TypeTuple', not as a 'pg_type'.

Also, I suspect the TypeTupleForm style usage is more common in the code.

-dg

David Gould            dg(at)informix(dot)com           510.628.3783 or 510.305.9468 
Informix Software  (No, really)         300 Lakeside Drive  Oakland, CA 94612
 - If simplicity worked, the world would be overrun with insects. -

In response to

Responses

pgsql-hackers by date

Next:From: David GouldDate: 1998-08-31 08:23:02
Subject: Re: [HACKERS] flock patch breaks things here
Previous:From: Bruce MomjianDate: 1998-08-31 07:58:47
Subject: Re: [HACKERS] odd pg_dump output?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group