Re: generating bootstrap entries for array types

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: ilmari(at)ilmari(dot)org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=)
Cc: John Naylor <jcnaylor(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: generating bootstrap entries for array types
Date: 2018-09-20 16:10:52
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

ilmari(at)ilmari(dot)org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> ilmari(at)ilmari(dot)org (Dagfinn Ilmari Mannsåker) writes:
>> Doing this in makes DBD::Pg lose its array type information,
>> since it uses Catalog::ParseData() to get it
>> ( May I
>> suggest moving gen_array_types() to and calling it from
>> ParseData() if the input file is pg_type.dat, so that it always returns
>> complete data?

> Attached is a proposed revision of this patch that does the above. It
> passes check-world, still works, and DBD::Pg is
> still able to get the array type information.

I find the way you did that (making the call dependent on
$preserve_formatting) to be a mighty ugly kluge. It causes ParseData
to know far more than it should about what callers are likely to do with
the data.

I'm inclined to think the right way is to do the expansion always,
and teach to drop autogenerated array types
on the way out, making this work more like the existing facilities
for default/computed fields.

The easiest way to make that happen seems to be to invent another, purely
internal metadata field, along the lines of "is_autogenerated_entry".
Fooling with that now ...

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2018-09-20 16:10:53 Re: v11 transaction semantics inside procedures
Previous Message Dave Cramer 2018-09-20 15:54:37 v11 transaction semantics inside procedures