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
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 |