Re: Dean Rasheed
> > I'll note that the current code uses PG's string representation of
> > strings which is meant to be round-trip safe when fed back into the
> > server. So quoted numeric values aren't a problem at all. (And that
> > part is fixable.)
>
> I'm not sure that being round-trip safe is a necessary goal here, but
> again, it's about the expectations for the feature. I was imagining
> that the goal was to produce something that an external tool would
> parse, rather than something Postgres would read back in. So not
> quoting numeric values seems desirable to produce output that better
> reflects the semantic content of the data (though it doesn't affect it
> being round-trip safe).
Getting it print numeric/boolean without quotes was actually easy, as
well as json(b). Implemented as the attached v2 patch.
But: not quoting json means that NULL and 'null'::json will both be
rendered as 'null'. That strikes me as a pretty undesirable conflict.
Does the COPY patch also do that?
> OTOH, this patch outputs the Postgres string representation of the
> object, which might be round-trip safe, but is not very convenient
> for any other tool to read.
For my use case, I need something that can be fed back into PG.
Reassembling all the json parts back into proper values would be a
pretty hard problem.
Perhaps there should be two output formats, one that's roundtrip-safe,
and one that represents json structures and composite values nicely.
Adding format-specific options could also be used to switch the output
between "array of json objects" and "one json object per line".
Christoph
