Re: pg_proc.h - Mailing list pgsql-hackers

From Dave Page
Subject Re: pg_proc.h
Date
Msg-id E7F85A1B5FF8D44C8A1AF6885BC9A0E4E7DF51@ratbert.vale-housing.co.uk
Whole thread Raw
In response to pg_proc.h  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: 10 November 2005 15:38
> To: Dave Page
> Cc: Andrew Dunstan; PostgreSQL-development
> Subject: Re: [HACKERS] pg_proc.h
>
> "Dave Page" <dpage@vale-housing.co.uk> writes:
> > I vote for fixing the file (but then I'm not doing the work).
> > Unused_oids or whatevers it's called is fine, but it's
> still handy to be
> > able to read the file easily.
>
> Our convention is that hand-assigned OIDs are *globally* unique,
> not just within the particular catalog.  This means you *must* use
> unused_oids to find a free OID; eyeballing the catalog listing isn't
> enough, even if it were in strict order.

Yes, I realise that, my point was that unused_oids doesn't make the file
more readable.

> Given that, I think "readability" really consists in keeping related
> functions together.  If we were going to do any wholesale reordering,
> I'd want to see it done with an eye to sorting the functions into
> logical groups, not a blind numeric sort.

That makes sense for groups of functions, but one-offs, or ones that are
not easily categorised will just end up being dumped anywhere in there.

You hack that file *far* more than I do though, so I can't really argue
against what you think would be most convenient.

Regards, Dave.


pgsql-hackers by date:

Previous
From: Fredrik Olsson
Date:
Subject: Re: Underlying view columns?
Next
From: "Magnus Hagander"
Date:
Subject: Re: Obtaining a source tree from CVS