Re: Do we need use more meaningful variables to replace 0 in catalog head files?

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Do we need use more meaningful variables to replace 0 in catalog head files?
Дата
Msg-id d732def2-6e1d-6dad-0465-728641bcb690@dunslane.net
обсуждение исходный текст
Ответ на Re: Do we need use more meaningful variables to replace 0 in catalog head files?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Do we need use more meaningful variables to replace 0 in catalog head files?
Re: Do we need use more meaningful variables to replace 0 in catalog head files?
Список pgsql-hackers

On 11/13/2016 04:54 AM, Andres Freund wrote:
> On 2016-11-12 12:30:45 -0500, Andrew Dunstan wrote:
>>
>> On 11/11/2016 11:10 AM, Tom Lane wrote:
>>> boolin: OID=1242 proname=boolin proargtypes="cstring" prorettype=bool
>>> boolin: prosrc=boolin provolatile=i proparallel=s
>>>
>>>
>>
>> I have written a little perl script to turn the pg_proc DATA lines into
>> something like the format suggested. In order to keep the space used as
>> small as possible, I used a prefix based on the OID. See attached result.
>>
>> Still plenty of work to go, e.g. grabbing the DESCR lines, and turning this
>> all back into DATA/DESCR lines, but I wanted to get this out there before
>> going much further.
>>
>> The defaults I used are below (commented out keys are not defaulted, they
>> are just there for completeness).
> In the referenced thread I'd started to work on something like this,
> until other people also said they'd be working on it.  I chose a
> different output format (plain Data::Dumper), but I'd added the parsing
> of DATA/DESCR and such to genbki.
>
> Note that I found that initdb performance is greatly increased *and*
> legibility is improvided, if types and such in the data files are
> expanded, and converted to their oids when creating postgres.bki.


Yeah, I have the type name piece, it was close to trivial. I just read 
in pg_type.h and stored the names/oids in a hash.

Data::Dumper is too wasteful of space. The thing I like about Tom's 
format is that it's nice and concise.

I'm not convinced the line prefix part is necessary, though. What I'm 
thinking of is something like this:

PROCDATA( oid=1242 name=boolin isstrict=t volatile=i parallel=s nargs=1    rettype=bool argtypes="cstring" src=boolin
);

Teaching Catalog.pm how to parse that and turn the type names back into 
oids won't be difficult. I already have code for the prefix version, and 
this would be easier since there is an end marker.

I'd actually like to roll up the DESCR lines in pg_proc.h into this too, 
they strike me as a bit of a wart. But I'm flexible on that.

If we can generalize this to other catalogs, then that will be good, but 
my inclination is to handle the elephant in the room (pg_proc.h) and 
worry about the gnats later.

>
> I basically made genbki/catalog.pm accept text whenever a column is of
> type regtype/regprocedure/. To then make use of that I converted a bunch
> of plain oid columns to their their reg* equivalent. That's also nice
> for just plain qureying of the catalogs ;)
>
> I don't think the code is going to be much use for you directlky, but it
> might be worthwhile to crib some stuff from the 0002 of the attached
> patches (based on 74811c4050921959d54d42e2c15bb79f0e2c37f3).


Thanks, I will take a look.

cheers

andrew





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Christian Convey
Дата:
Сообщение: Re: Tackling JsonPath support
Следующее
От: Magnus Hagander
Дата:
Сообщение: Physical append-only tables