tydedef extraction - back to the future - Mailing list pgsql-hackers

From Andrew Dunstan
Subject tydedef extraction - back to the future
Date
Msg-id 43a819bb-8c92-4a0d-a8ce-01221a5ab20f@dunslane.net
Whole thread Raw
Responses Re: tydedef extraction - back to the future
Re: tydedef extraction - back to the future
List pgsql-hackers
Many years ago we in effect moved maintenance of the typedefs list for 
pgindent into the buildfarm client. The reason was that there were a 
number of typedefs that were platform dependent, so we wanted to have 
coverage across a number of platforms to get a comprehensive list.

Lately, this has caused some dissatisfaction, with people wanting the 
logic for this moved back into core code, among other reasons so we're 
not reliant on one person - me - for changes. I share this 
dissatisfaction. Indeed, IIRC the use of the buildfarm was originally 
intended as something of a stopgap. Still, we do need to multi-platform 
support.

Attached is an attempt to thread this needle. The core is a new perl 
module that imports the current buildfarm client logic. The intention is 
that once we have this, the buildfarm client will switch to using the 
module (if found) rather than its own built-in logic. There is precedent 
for this sort of arrangement (AdjustUpgrade.pm). Accompanying the new 
module is a standalone perl script that uses the new module, and 
replaces the current shell script (thus making it more portable).

One thing this is intended to provide for is getting typedefs for 
non-core code such as third party extensions, which isn't entirely 
difficult 
(<https://adpgtech.blogspot.com/2015/05/running-pgindent-on-non-core-code-or.html>) 
but it's not as easy as it should be either.

Comments welcome.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Attachment

pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: Streaming read-ready sequential scan code
Next
From: Tom Lane
Date:
Subject: Re: tydedef extraction - back to the future