Re: pg_proc.h

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_proc.h
Date: 2005-11-11 08:08:11
Message-ID: E7F85A1B5FF8D44C8A1AF6885BC9A0E4E7DF51@ratbert.vale-housing.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: 10 November 2005 15:38
> To: Dave Page
> Cc: Andrew Dunstan; PostgreSQL-development
> Subject: Re: [HACKERS] pg_proc.h
>
> "Dave Page" <dpage(at)vale-housing(dot)co(dot)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.

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2005-11-11 08:46:39 Re: Obtaining a source tree from CVS
Previous Message Fredrik Olsson 2005-11-11 07:36:05 Re: Underlying view columns?