Re: WIP: a way forward on bootstrap data

From: Mark Dilger <hornschnorter(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, John Naylor <jcnaylor(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: a way forward on bootstrap data
Date: 2018-04-25 21:43:53
Message-ID: 20AA9069-CB87-4457-ADC6-C88D35617CA3@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


>>
>>>> + text prosrc BKI_DEFAULT("${proname}") BKI_FORCE_NOT_NULL;
>>
>>> That one I kinda like.
>>
>> Agreed, this seems more compelling. However, I think we need more than
>> one compelling example to justify the additional infrastructure.
>
> I'll look for more.

There are two more that seem reasonable optimizations in pg_cast.h:

diff --git a/src/include/catalog/pg_cast.h b/src/include/catalog/pg_cast.h
index 7f4a25b2da..98794df7f8 100644
--- a/src/include/catalog/pg_cast.h
+++ b/src/include/catalog/pg_cast.h
@@ -37,13 +37,13 @@ CATALOG(pg_cast,2605,CastRelationId)
Oid casttarget BKI_LOOKUP(pg_type);

/* cast function; 0 = binary coercible */
- Oid castfunc BKI_LOOKUP(pg_proc);
+ Oid castfunc BKI_DEFAULT("${casttarget}(${castsource})") BKI_LOOKUP(pg_proc);

/* contexts in which cast can be used */
char castcontext;

/* cast method */
- char castmethod;
+ char castmethod BKI_DEFAULT("/${castfunc} == 0 ? 'b' : 'f'/e");
} FormData_pg_cast;

/* ----------------

Which would convert numerous lines like:

{ castsource => 'money', casttarget => 'numeric', castfunc => 'numeric(money)',
castcontext => 'a', castmethod => 'f' },

To shorter lines like:

{ castsource => 'money', casttarget => 'numeric', castcontext => 'a' },

which is great, because all you really are trying to tell the postgres system is
that when you cast from numeric to money it has to be an explicit assignment and
not an implicit cast. The extra stuff about castfunc and castmethod just gets in
the way of understanding what is being done.

There are another two in pg_opclass.h:

diff --git a/src/include/catalog/pg_opclass.h b/src/include/catalog/pg_opclass.h
index b980327fc0..9f528f97c0 100644
--- a/src/include/catalog/pg_opclass.h
+++ b/src/include/catalog/pg_opclass.h
@@ -52,7 +52,7 @@ CATALOG(pg_opclass,2616,OperatorClassRelationId)
Oid opcmethod BKI_LOOKUP(pg_am);

/* name of this opclass */
- NameData opcname;
+ NameData opcname BKI_DEFAULT("${opcintype}_ops");

/* namespace of this opclass */
Oid opcnamespace BKI_DEFAULT(PGNSP);
@@ -61,7 +61,7 @@ CATALOG(pg_opclass,2616,OperatorClassRelationId)
Oid opcowner BKI_DEFAULT(PGUID);

/* containing operator family */
- Oid opcfamily BKI_LOOKUP(pg_opfamily);
+ Oid opcfamily BKI_DEFAULT("${opcmethod}/${opcintype}_ops") BKI_LOOKUP(pg_opfamily);

/* type of data indexed by opclass */
Oid opcintype BKI_LOOKUP(pg_type);

Which would convert numerous lines like the following line from pg_opclass.dat:

{ opcmethod => 'btree', opcname => 'bytea_ops', opcfamily => 'btree/bytea_ops',
opcintype => 'bytea' },

to much easier to read lines like:

{ opcmethod => 'btree', opcintype => 'bytea' },

which is also great, because you're really just declaring that type bytea has a
btree opclass and letting the system do the rest of the work. Having to manually
specify opfamily and the opname just clutters the row and makes it less intuitive.

There are a bunch more of varying quality, depending on which automations
you like or don't like.

mark

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2018-04-25 22:13:03 Re: Corrupted btree index on HEAD because of covering indexes
Previous Message Alexander Korotkov 2018-04-25 21:09:10 Re: Corrupted btree index on HEAD because of covering indexes