Re: WIP: a way forward on bootstrap data

From: John Naylor <jcnaylor(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: David Fetter <david(at)fetter(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: a way forward on bootstrap data
Date: 2017-12-22 04:16:02
Message-ID: CAJVSVGWLgVXoZDYCgcMLXQ_ZtCyC=BjNWJ_YJ74wyaGJmm2Unw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/22/17, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> Hmm, patch 0008 removes data lines from the .h but leaves the dependent
> OID define lines around:
>
> #define BTREE_AM_OID 403
>
> This is not good, because then the define depends on data that appears
> in a distant file.

I see what you mean.

> Another consideration is that the current system has
> the property that these OIDs are discoverable by a hacker by navigating
> to the containing .h file; and a missing symbol is easily fixable if
> they need to hardcode the OID for which there isn't a symbol yet.

I'm not sure I follow you here.

> Maybe a generated .h file containing defines for OIDs from all catalogs
> is okay. Of course, not all symbols are to be listed -- we should have
> a special marker in the data lines for those that are. Maybe something
> like this
>
> { oid => '403', descr => 'b-tree index access method',
> amname => 'btree', amhandler => 'bthandler', amtype => 'i',
> cpp_symbol => 'BTREE_AM_OID' },
>
> (where 'cpp_symbol' would be skipped by genbki explicitly).

The last part makes sense and would be a fairly mechanical change. I'm
not sure of the best way to include those generated symbols back in
the code again, though. I think a single file might not be desirable
because of namespace pollution. The alternative would be to have, say,
pg_am.h include pg_am_sym.h. More complex but doable. Also, no need to
skip non-data values explicitly. The code knows where to find the
schema. :-)

Thanks for pushing 1 and 2, BTW.

-John Naylor

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chapman Flack 2017-12-22 04:17:29 archive restore command failure status [was Re: patch proposal]
Previous Message Haribabu Kommi 2017-12-22 04:11:07 Re: Enhance pg_stat_wal_receiver view to display connected host