pá 17. 5. 2024 v 16:04 odesílatel Robert Haas
napsal:
> On Fri, May 17, 2024 at 9:42 AM Christoph Berg wrote:
> > Thanks for summarizing the thread.
> >
> > Things mentioned in the thread:
> >
> > 1) rendering of SQL NULLs - include or omit the column
> >
> > 2) rendering of JSON values - both "
On Fri, May 17, 2024 at 9:42 AM Christoph Berg wrote:
> Thanks for summarizing the thread.
>
> Things mentioned in the thread:
>
> 1) rendering of SQL NULLs - include or omit the column
>
> 2) rendering of JSON values - both "quoted string" and "inline as
>JSON" make sense
>
> 3) not quoting n
Re: Robert Haas
> IMHO, the big problem here is that different people want different
> corner-case behaviors and it's not clear what to do about that. I
> don't think there's a single vote for "don't do this at all". So if
> there is a desire to take this work forward, the goal probably ought
> to
On Tue, Jan 23, 2024 at 11:35 AM Christoph Berg wrote:
> Ack.
The last version of this patch was posted on January 22nd and got a
bunch of replies, so I'm marking
https://commitfest.postgresql.org/48/4707/ as Returned with Feedback
for now. Please feel free to update the status of the patch when
Re: Laurenz Albe
> > I'd just stop the flood right before it starts...
>
> I'd stop the flood right after json/jsonb.
Nod. I do see a point here, given it's "json in json", and not
"something else in json". Will try to make it work with \gedit.
> Arrays as database columns are probably too rare
On Tue, 2024-01-23 at 16:36 +0100, Christoph Berg wrote:
> Re: Laurenz Albe
> > I am kind of unhappy about this change. It seems awkward and undesirable
> > so have JSON values decorated with weird quoting in JSON output.
> > I understand the motivation, but I bet it's not what will make users
> >
Re: Laurenz Albe
> If you import the data into an existing structure, you don't need the
> metadata.
Also, since you were running the query yourself, you should know what
columns you were expecting.
Christoph
On Tue, 2024-01-23 at 08:01 -0700, David G. Johnston wrote:
> I do think that the output should include a metadata section that lists all of
> the actual columns in the result, the column position, and since we have the
> info available, the data type name and possibly OID. Then any column name
>
Re: Laurenz Albe
> I am kind of unhappy about this change. It seems awkward and undesirable
> so have JSON values decorated with weird quoting in JSON output.
> I understand the motivation, but I bet it's not what will make users
> happy.
Well, why stop at JSON, and not represent any array type a
On Tue, Jan 23, 2024 at 7:35 AM Stefan Keller wrote:
> Am Di., 23. Jan. 2024 um 15:15 Uhr schrieb Laurenz Albe
> :
> > I understand the motivation, but I bet it's not what will make users
> > happy.
> >
> > If you need to disambiguate between SQL NULL and JSON null, my
> > preferred solution woul
Am Di., 23. Jan. 2024 um 15:15 Uhr schrieb Laurenz Albe
:
> I understand the motivation, but I bet it's not what will make users
> happy.
>
> If you need to disambiguate between SQL NULL and JSON null, my
> preferred solution would be to omit SQL NULL columns from the output
> altogether.
I fully
On Mon, 2024-01-22 at 16:19 +0100, Christoph Berg wrote:
> What I did now in v3 of this patch is to print boolean and numeric
> values (ints, floats, numeric) without quotes, while adding the quotes
> back to json. This solves the NULL vs 'null'::json problem.
The patch is working as advertised.
Re: Laurenz Albe
> > But I do think it has positive
> > value. If we produce output that could be ingested back into PG later
> > with the right tool, that leaves the door open for someone to build
> > the tool later even if we don't have it today. If we produce output
> > that loses information, n
On Wed, 2024-01-17 at 14:52 -0500, Robert Haas wrote:
> Let me start by clarifying that I'm OK with sacrificing
> round-trippability here as long as we do it thoughtfully.
Got you.
> I'm not quite sure that addresses all the issues, though. For
> instance, consider that 1.00::numeric and 1.0::nu
On Wed, Jan 17, 2024 at 4:30 AM Laurenz Albe wrote:
> As mentioned in my other mail, I was talking about the psql output
> format "csv" rather than about COPY.
Oh. Well, I think it's sad that the psql format csv has that property.
Why doesn't it adopt COPY's handling?
> I agree that it is desira
On 2024-01-17 We 03:52, Laurenz Albe wrote:
On Tue, 2024-01-16 at 11:49 -0500, Andrew Dunstan wrote:
On 2024-01-16 Tu 11:07, Laurenz Albe wrote:
On Tue, 2024-01-09 at 16:51 +, Dean Rasheed wrote:
On Tue, 9 Jan 2024 at 14:35, Christoph Berg wrote:
Getting it print numeric/boolean withou
On Tue, 2024-01-16 at 14:12 -0500, Robert Haas wrote:
> On Tue, Jan 16, 2024 at 11:07 AM Laurenz Albe
> wrote:
> > "Round-trip safety" is not so important. If you want to move data from
> > PostgreSQL to PostgreSQL, you use the plain or the binary format.
> > The CSV format by default renders NU
On Tue, 2024-01-16 at 11:49 -0500, Andrew Dunstan wrote:
> On 2024-01-16 Tu 11:07, Laurenz Albe wrote:
> > On Tue, 2024-01-09 at 16:51 +, Dean Rasheed wrote:
> > > On Tue, 9 Jan 2024 at 14:35, Christoph Berg wrote:
> > > > Getting it print numeric/boolean without quotes was actually easy, as
>
On Tue, Jan 16, 2024 at 11:07 AM Laurenz Albe wrote:
> "Round-trip safety" is not so important. If you want to move data from
> PostgreSQL to PostgreSQL, you use the plain or the binary format.
> The CSV format by default renders NULL and empty strings identical, and
> I don't think anybody objec
On 2024-01-16 Tu 11:07, Laurenz Albe wrote:
On Tue, 2024-01-09 at 16:51 +, Dean Rasheed wrote:
On Tue, 9 Jan 2024 at 14:35, Christoph Berg wrote:
Getting it print numeric/boolean without quotes was actually easy, as
well as json(b). Implemented as the attached v2 patch.
But: not quoting
On Tue, 2024-01-09 at 16:51 +, Dean Rasheed wrote:
> On Tue, 9 Jan 2024 at 14:35, Christoph Berg wrote:
> >
> > 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 '
[cc'ing Joe]
On Tue, 9 Jan 2024 at 14:35, Christoph Berg wrote:
>
> 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 str
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
On Tue, 9 Jan 2024 at 09:43, Christoph Berg wrote:
>
> I can see we probably wouldn't want two different output formats named
> json, but the general idea of "allow psql to format results as json of
> strings" makes a lot of sense, so we should try to make it work. Does
> it even have to be compat
Re: Dean Rasheed
> I can see the appeal in this feature. However, as it stands, this
> isn't compatible with copy format json, and I think it would need to
> duplicate quite a lot of the JSON output code in client-side code to
> make it compatible.
I can see we probably wouldn't want two different
On Mon, 2024-01-08 at 18:43 +, Dean Rasheed wrote:
> I can see the appeal in this feature. However, as it stands, this
> isn't compatible with copy format json, and I think it would need to
> duplicate quite a lot of the JSON output code in client-side code to
> make it compatible.
>
> Conside
On Mon, 18 Dec 2023 at 16:34, Jelte Fennema-Nio wrote:
>
> On Mon, 18 Dec 2023 at 16:38, Christoph Berg wrote:
> > We'd want both patches even if they do the same thing on two different
> > levels, I'd say.
>
> Makes sense.
>
I can see the appeal in this feature. However, as it stands, this
isn'
On Mon, 18 Dec 2023 at 16:38, Christoph Berg wrote:
> We'd want both patches even if they do the same thing on two different
> levels, I'd say.
Makes sense. One thing I was still wondering is if it wouldn't be
easier to wrap all queries in "copy (select whatever) to stdout
(format json)" automati
Re: Jelte Fennema-Nio
> This seems useful to me too, but my usecases would also be solved (and
> possibly better solved) by adding JSON support to COPY as proposed
> here:
> https://www.postgresql.org/message-id/flat/CALvfUkBxTYy5uWPFVwpk_7ii2zgT07t3d-yR_cy4sfrrLU%3Dkcg%40mail.gmail.com
Thanks fo
On Mon, 18 Dec 2023 at 15:56, Christoph Berg wrote:
> I noticed psql was lacking JSON formatting of query results which I
> need for a follow-up patch.
This seems useful to me too, but my usecases would also be solved (and
possibly better solved) by adding JSON support to COPY as proposed
here:
Re: To PostgreSQL Hackers
> On the command line, the format is selected by `psql --json` and `psql -J`.
Among other uses, it enables easy post-processing of psql output using `jq`:
$ psql -lJ | jq
[
{
"Name": "myon",
"Owner": "myon",
"Encoding": "UTF8",
"Locale Provider": "libc"
I noticed psql was lacking JSON formatting of query results which I
need for a follow-up patch. It also seems useful generally, so here's
a patch:
postgres=# \pset format json
Output format is json.
postgres=# select * from (values ('one', 2, 'three'), ('four', 5, 'six')) as
sub(a, b, c);
[
{ "a"
32 matches
Mail list logo
