Re: WIP: Generic functions for Node types using generated metadata

On Fri, Sep 20, 2019 at 03:43:54PM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-09-19 22:18:57 -0700, Andres Freund wrote:
> > While working on this I evolved the node string format a bit:
> >
> > 1) Node types start with the their "normal" name, rather than
> > uppercase. There seems little point in having such a divergence.
> >
> > 2) The node type is followed by the node-type id. That allows to more
> > quickly locate the corresponding node metadata (array and one name
> > recheck, rather than a binary search). I.e. the node starts with
> > "{Scan 18 " rather than "{SCAN " as before.
> >
> > 3) Nodes that contain other nodes as sub-types "inline", still emit {}
> > for the subtype. There's no functional need for this, but I found the
> > output otherwise much harder to read. E.g. for mergejoin we'd have
> > something like
> >
> > {MergeJoin 37 :join {Join 35 :plan {Plan ...} :jointype JOIN_INNER ...} :skip_mark_restore true ...}
> >
> > 4) As seen in the above example, enums are decoded to their string
> > values. I found that makes the output easier to read. Again, not
> > functionally required.
> >
> > 5) Value nodes aren't emitted without a {Value ...} anymore. I changed
> > this when I expanded the WRITE/READ tests, and encountered failures
> > because the old encoding is not entirely rountrip safe
> > (e.g. -INT32_MIN will be parsed as a float at raw parse time, but
> > after write/read, it'll be parsed as an integer). While that could be
> > fixed in other ways (e.g. by emitting a trailing . for all floats), I
> > also found it to be clearer this way - Value nodes are otherwise
> > undistinguishable from raw strings, raw numbers etc, which is not
> > great.
> >
> > It'd also be easier to now just change the node format to something else.
>
> E.g. to just use json.

+many

JSON's been around long enough to give some assurance that it's not
going away, and it's pretty simple.

Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate