Re: WIP: a way forward on bootstrap data

From: John Naylor <jcnaylor(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, David Fetter <david(at)fetter(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: a way forward on bootstrap data
Date: 2018-01-13 11:47:29
Message-ID: CAJVSVGUuC1r5+FDam5xCdODmU2D1sB6CazQPWYFw00ir8sbVnA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1/13/18, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> According to my understanding, part of what's going on here is that
> we're going to teach genbki.pl to parse these object references and
> convert them to hard-coded OIDs in the emitted BKI file. That seems
> good to me, but one thing we're going to need is a spec for how
> genbki.pl knows what to do.

I don't know if it qualifies as a spec, but here's my implementation:

Use dummy type aliases in the header files: regam, regoper, regopf, and regtype
These are #defined away in genbki.h:

+/* ----------------
+ * Some columns of type Oid have human-readable entries that are
+ * resolved when creating postgres.bki.
+ * ----------------
+ */
+#define regam Oid
+#define regoper Oid
+#define regopf Oid
+#define regtype Oid

Likewise, in genbki.pl (and I just noticed a typo, s/names/types/):

+# We use OID aliases to indicate when to do OID lookups, so column names
+# have to be turned back into 'oid' before writing the CREATE command.
+my %RENAME_REGOID = (
+ regam => 'oid',
+ regoper => 'oid',
+ regopf => 'oid',
+ regtype => 'oid');
+

When genbki.pl sees one of these type aliases, it consults the
appropriate lookup table, exactly how we do now for regproc. One
possibly dubious design point is that I declined to teach the
pg_attribute logic about this, so doing lookups in tables with schema
macros has to be done explicitly. There is only one case of this right
now, and I noted the tradeoff:

+ # prorettype
+ # Note: We could handle this automatically by using the
+ # 'regtype' alias, but then we would have to teach
+ # morph_row_for_pgattr() to change the attribute type back to
+ # oid. Since we have to treat pg_proc differently anyway,
+ # just do the type lookup manually here.
+ my $rettypeoid = $regtypeoids{ $bki_values{prorettype}};
+ $bki_values{prorettype} = $rettypeoid
+ if defined($rettypeoid);

This is all in patch 0011.

-John Naylor

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2018-01-13 12:32:42 Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)
Previous Message John Naylor 2018-01-13 10:43:09 Re: WIP: a way forward on bootstrap data