Re: proposal \gcsv

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Daniel Verite <daniel(at)manitou-mail(dot)org>, Vik Fearing <vik(at)postgresfriends(dot)org>, Erik Rijkers <er(at)xs4all(dot)nl>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal \gcsv
Date: 2020-04-07 07:29:58
Message-ID: CAFj8pRDJ-WvacB95Emj=hS_Mfm_qOBgUgRELVktM-WjkVm_9=A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

út 7. 4. 2020 v 2:28 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> Here's a WIP patch for the parenthesized-options route.
>
> I realized that if we make the options be single words in the form
> name=value, we can easily handle the shortcut forms with no value.
> So that's what this does.
>
> What this does *not* do is offer any solution to the question of
> how to put a right paren as the last character of a pset option
> value. I don't really see any easy way to handle that, but maybe
> we can punt for now.
>
> Also no docs or test cases, but I see no point in putting effort into
> that in advance of consensus that this is what we want.
>
> 0001 is some save/restore infrastructure that we'd need for pretty
> much all of the proposals on the table, and then 0002 improves the
> command itself.
>

looks well

just note to syntax

your patch supports syntax

(option1=value option2=value)

It looks little bit inconsistent and unusual

should be better comma separated list?

(option1=value, option2=value)

Regards

Pavel

>
> regards, tom lane
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-04-07 07:30:43 Re: [HACKERS] Restricting maximum keep segments by repslots
Previous Message Andres Freund 2020-04-07 07:24:18 Re: Catalog invalidations vs catalog scans vs ScanPgRelation()