On 1/13/18, Tom Lane <t...@sss.pgh.pa.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
