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

On 11/11/2016 03:03 AM, Magnus Hagander wrote:
>
> On Nov 11, 2016 00:53, "Jan de Visser" <jan(at)de-visser(dot)net
> <mailto:jan(at)de-visser(dot)net>> wrote:
> >
> > On 2016-11-09 10:47 AM, Tom Lane wrote:
> >
> >> Amit Langote <amitlangote09(at)gmail(dot)com
> <mailto:amitlangote09(at)gmail(dot)com>> writes:
> >>>
> >>> On Wed, Nov 9, 2016 at 11:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us
> <mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us>> wrote:
> >>>>
> >>>> Hmm, that's from 2009. I thought I remembered something much
> more recent,
> >>>> like last year or so.
> >>>
> >>> This perhaps:
> >>> * Re: Bootstrap DATA is a pita *
> >>>
> https://www.postgresql.org/message-id/flat/CAOjayEfKBL-_Q9m3Jsv6V-mK1q8h%3Dca5Hm0fecXGxZUhPDN9BA%40mail.gmail.com
> >>
> >> Yeah, that's the thread I remembered. I think the basic conclusion was
> >> that we needed a Perl script that would suck up a bunch of data
> from some
> >> representation that's more edit-friendly than the DATA lines, expand
> >> symbolic representations (regprocedure etc) into numeric OIDs, and
> write
> >> out the .bki script from that. I thought some people had
> volunteered to
> >> work on that, but we've seen no results ...
> >>
> >> regards, tom lane
> >>
> >>
> >
> > Would a python script converting something like json or yaml be
> acceptable? I think right now only perl is used, so it would be a new
> build chain tool, albeit one that's in my (very humble) opinion much
> better suited to the task.
> >
>
> Python or perl is not what matters here really. For something as
> simple as this (for the script) it doesn't make a real difference. I
> personally prefer python over perl in most cases, but our standard is
> perl so we should stick to that.
>
> The issues is coming up with a format that people like and think is an
> improvement.
>
> If we have that and a python script for our, someone would surely
> volunteer to convert that part. But we need to start by solving the
> actual problem.
>
>

+1. If we come up with an agreed format I will undertake to produce the
requisite perl script. So let's reopen the debate on the data format. I
want something that doesn't consume large numbers of lines per entry. If
we remove defaults in most cases we should be able to fit a set of
key/value pairs on just a handful of lines.

cheers

andrew