Re: WIP: a way forward on bootstrap data

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: John Naylor <jcnaylor(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: a way forward on bootstrap data
Date: 2018-04-05 04:10:03
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Here are the results of an evening's desultory hacking on v13.

I was dissatisfied with the fact that we still had several
function-referencing columns that had numeric instead of symbolic
contents, for instance pg_aggregate.aggfnoid. Of course, the main reason
is that those are declared regproc but reference functions with overloaded
names, which regproc can't handle. Now that the lookups are being done in there's no reason why we have to live with that limitation.
In the attached, I've generalized the BKI_LOOKUP(pg_proc) code so that
you can use either regproc-like or regprocedure-like notation, and then
applied that to relevant columns.

I did not like the hard-wired handling of proargtypes and proallargtypes
in; it hardly seems impossible that we'll want similar
conversions for other array-of-OID columns in future. After a bit of
thought, it seemed like we could allow

oidvector proargtypes BKI_LOOKUP(pg_type);

Oid proallargtypes[1] BKI_DEFAULT(_null_) BKI_LOOKUP(pg_type);

and just teach that if a lookup rule is attached to
an oidvector or Oid[] column, it means to apply the rule to
each array element individually.

I also changed so that it'd warn about entries that aren't
recognized by the lookup rules. This seems like a good idea for
catching errors, such as (ahem) applying BKI_LOOKUP to a column
that isn't even an OID.

bootstrap-v13-delta.patch is a diff atop your patch series for the
in-tree files, and convert_oid2name.patch adjusts that script to
make use of the additional conversion capability.

regards, tom lane

Attachment Content-Type Size
bootstrap-v13-delta.patch text/x-diff 13.6 KB
convert_oid2name.patch text/x-diff 4.0 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2018-04-05 04:47:59 Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key
Previous Message Thomas Munro 2018-04-05 04:04:22 Unstable number of workers in select_parallel test on spurfowl