Re: Do we need use more meaningful variables to replace 0 in catalog head files?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Jan de Visser <jan(at)de-visser(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Hao Lee <mixtrue(at)gmail(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Do we need use more meaningful variables to replace 0 in catalog head files?
Date: 2016-11-11 16:10:23
Message-ID: 28314.1478880623@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> +1. If we come up with an agreed format I will undertake to produce the
> requisite perl script. So let's reopen the debate on the data format. I
> want something that doesn't consume large numbers of lines per entry. If
> we remove defaults in most cases we should be able to fit a set of
> key/value pairs on just a handful of lines.

The other reason for keeping the entries short is to prevent patch
misapplications: you want three or less lines of context to be enough
to uniquely identify which line you're changing. So something with,
say, a bunch of <tag></tag> overhead, with that markup split onto
separate lines, would be a disaster. This may mean that we can't
get too far away from the DATA-line approach :-(.

Or maybe what we need to do is ensure that there's identification info on
every line, something like (from the first entry in pg_proc.h)

boolin: OID=1242 proname=boolin proargtypes="cstring" prorettype=bool
boolin: prosrc=boolin provolatile=i proparallel=s

(I'm imagining the prefix as having no particular semantic significance,
except that identical values on successive lines denote fields for a
single catalog row.)

With this approach, even if you had blocks of boilerplate-y lines
that were the same for many successive functions, the prefixes would
keep them looking unique to "patch".

On the other hand, Andrew might be right that with reasonable defaults
available, the entries would mostly be short enough that there wouldn't
be much of a problem anyway. This example certainly looks that way.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Karlsson 2016-11-11 17:53:33 Re: pg_sequence catalog
Previous Message Francisco Olarte 2016-11-11 15:03:06 Re: Why PostgreSQL doesn't implement a semi sync replication?