Re: csv format for psql

Tom Lane wrote: > what I did instead was just to make > csv_print_field force field quoting if any of these cases could > possibly apply. That will result in excess quoting in some > cases, but I think that's fine, since they're all pretty uncommon. Indeed. > (BTW, it seems only chance

Re: csv format for psql

> > Pushed with that correction and some other last-minute review. > Great! Thank you Pavel > > regards, tom lane > >

Re: csv format for psql

"Daniel Verite" writes: >> A proposed fix is attached. print_csv_vertical() is left unchanged >> because it's not possible currently to end up with \. alone >> on a line with the expanded display > On second thought, it is possible > postgres=# \pset format csv > Output format is csv. >

Re: csv format for psql

I wrote: > A proposed fix is attached. print_csv_vertical() is left unchanged > because it's not possible currently to end up with \. alone > on a line with the expanded display On second thought, it is possible postgres=# \pset format csv Output format is csv. postgres=# \pset

Re: csv format for psql

Tom Lane wrote: > OK, reasonable arguments were made why not to allow multi-character > separators. Should we then match the server and insist on a single-byte > separator? It's a bit inconsistent if psql can be made to emit "csv" > files that COPY can't read, especially when it's

Re: csv format for psql

"David G. Johnston" writes: > On Sun, Nov 25, 2018 at 6:27 PM Tom Lane wrote: >> 1. Are we limiting the separator to be a single-byte character or not? > I agree with what others have said that expanding functionality in > this direction is more likely to mask errors than be useful. OK,

Re: csv format for psql

On Sun, Nov 25, 2018 at 6:27 PM Tom Lane wrote: > I think there are two remaining points to settle: > > 1. Are we limiting the separator to be a single-byte character or not? I agree with what others have said that expanding functionality in this direction is more likely to mask errors than be

Re: csv format for psql

Tom Lane wrote: > And, in fact, right now *none* of psql's table output formats is both > unambiguous and reasonably simple/popular to use. So the astonishing > thing about this patch, IMO, is that we didn't do it a decade ago. Yeah, that's what motivated this submission in the first

Re: csv format for psql

n Mon, Nov 26, 2018 at 5:53 AM Pavel Stehule wrote: > > > po 26. 11. 2018 v 5:36 odesílatel Andrew Gierth < > and...@tao11.riddles.org.uk> napsal: > >> > "Tom" == Tom Lane writes: >> >> Tom> Or we could kill both issues by hard-wiring the separator as ','. >> >> Using ';' for the delimiter

Re: csv format for psql

On Sun, Nov 25, 2018 at 11:23 PM Tom Lane wrote: > Corey Huinker writes: > > Could we have another output type called "separated" that uses the > existing > > --fieldsep / --recordsep? > > Uh, what's the difference from the existing unaligned format? > No footer and I guess we'd want to escape

Re: csv format for psql

po 26. 11. 2018 v 5:36 odesílatel Andrew Gierth napsal: > > "Tom" == Tom Lane writes: > > Tom> Or we could kill both issues by hard-wiring the separator as ','. > > Using ';' for the delimiter isn't all that rare. > ; is default for CSV produced by MS Excel in Czech mutation - so for some

Re: csv format for psql

> "Tom" == Tom Lane writes: Tom> Or we could kill both issues by hard-wiring the separator as ','. Using ';' for the delimiter isn't all that rare. But I don't see any reason to allow multibyte or non-ascii characters or arbitrary strings. -- Andrew (irc:RhodiumToad)

Re: csv format for psql

Corey Huinker writes: > Could we have another output type called "separated" that uses the existing > --fieldsep / --recordsep? Uh, what's the difference from the existing unaligned format? regards, tom lane

Re: csv format for psql

> > > Or we could kill both issues by hard-wiring the separator as ','. +1 I've never encountered a situation where a customer wanted a custom delimiter AND quoted strings. So either they wanted pure CSV or a customed TSV. Could we have another output type called "separated" that uses the

Re: csv format for psql

Fabien COELHO writes: > Basically the proposed patch addresses a simple and convenient use case > which are neither addressed by \copy nor COPY. The fact that more options > are available with these commands does it precludes its usefulness as is. Yeah, I agree that this option is useful

Re: csv format for psql

Bonjour Michaël, But again COPY is concerned with importing the data that preexists, even if it's weird, whereas a psql output formats are not. Hm. I checked the contents of the patch in details which provide output consistent with COPY, but after looking at the global picture I am getting

Re: csv format for psql

po 12. 11. 2018 v 5:19 odesílatel David G. Johnston < david.g.johns...@gmail.com> napsal: > On Friday, November 9, 2018, Michael Paquier wrote: > >> On Fri, Nov 09, 2018 at 05:28:07PM +0100, Daniel Verite wrote: >> > But again COPY is concerned with importing the data that preexists, >> > even

Re: csv format for psql

On Friday, November 9, 2018, Michael Paquier wrote: > On Fri, Nov 09, 2018 at 05:28:07PM +0100, Daniel Verite wrote: > > But again COPY is concerned with importing the data that preexists, > > even if it's weird, whereas a psql output formats are not. > > Hm. I checked the contents of the patch

Re: csv format for psql

Michael Paquier wrote: > - The experience is confusing, as the psql format uses different options > than the backend to do the same things: > -- tuples_only instead of HEADER. > -- fieldsep_csv instead of DELIMITER > -- null is an equivalent of the one with the same name, which is >

Re: csv format for psql

Michael Paquier wrote: > Still what's the point except complicating the code? We don't care > about anything fancy in the backend-side ProcessCopyOptions() when > checking cstate->delim, and having some consistency looks like a good > thing to me. The backend has its reasons that don't

Re: csv format for psql

On Fri, Nov 09, 2018 at 11:40:44AM +0100, Daniel Verite wrote: > The above is meant to accept a multibyte character as the separator, > in which case strlen(value) would be greater than 1. Still what's the point except complicating the code? We don't care about anything fancy in the backend-side

Re: csv format for psql

Michael Paquier wrote: > +/* check for value being non-empty and with an MB length of 1 */ > +if (*value == '\0' || value[PQmblen(value, pset.encoding)] != '\0') > > It seems to me that this can just be replaced with that: > if (strlen(value) != 1) The above is meant to accept a

Re: csv format for psql

pá 9. 11. 2018 v 6:57 odesílatel Michael Paquier napsal: > On Thu, Nov 08, 2018 at 01:58:34PM +0900, Michael Paquier wrote: > > Anyway, I am still going through the patch, so no need to send a new > > version for now. > > Okay, I have done a round of more in-depth review, and the patch looks >

Re: csv format for psql

On Wed, Nov 07, 2018 at 05:36:54PM +0100, Daniel Verite wrote: > I guess it could go into a #define in psql/settings.h, along with > these: > #define DEFAULT_FIELD_SEP "|" > #define DEFAULT_RECORD_SEP "\n" Yes. > Yes, since we support column names with embedded newlines (even > though it's hard

Re: csv format for psql

Michael Paquier wrote: > -C could also be useful for other things, say compression. The patch does not grab any short letter, as the consensus went that way. > + pset.popt.topt.fieldSepCsv = pg_strdup(","); > Let's store that in a variable instead of hardcoding it. I guess it could

Re: csv format for psql

Bonjour Michaël, First, it seems to me that it is necessary to overcomplicate the interface of psql for that. Most of the other formats don't have their own switch, and it is perfectly possible to use CSV format with just --pset=format=csv. Although this work, it is not very user friendly

Re: csv format for psql

On Tue, Nov 06, 2018 at 02:57:15PM +0100, Daniel Verite wrote: > Here's a rebased version following these changes. Thanks for doing a rebase. First, it seems to me that it is necessary to overcomplicate the interface of psql for that. Most of the other formats don't have their own switch, and

Re: csv format for psql

Michael Paquier wrote: > Ordering them in alphabetical order is a good idea due to the high > number of options available, and more would pile up even if this > separates a bit "aligned" and "unaligned", so I have have separated > those diffs from the core patch and committed it, leaving

Re: csv format for psql

On Sat, Nov 03, 2018 at 09:45:14AM +0100, Fabien COELHO wrote: > Patch applies cleanly, compiles, make check ok, doc gen ok. > > Fine with me. I switched the patch to "Ready". I have begun looking at this patch, and there are some noise diffs because of the reordering of the items you are doing

Re: csv format for psql

Bonjour Daniel, Here's a rebased version with a couple regression tests added per the discussions during the previous CF. Now at https://commitfest.postgresql.org/20/1861/ Patch applies cleanly, compiles, make check ok, doc gen ok. Fine with me. I switched the patch to "Ready". --

Re: csv format for psql

Michael Paquier wrote: > If you can produce a new version, please feel free to post it. Here's a rebased version with a couple regression tests added per the discussions during the previous CF. Now at https://commitfest.postgresql.org/20/1861/ Best regards, -- Daniel Vérité

Re: csv format for psql

On Tue, Aug 28, 2018 at 08:54:02PM +0200, Fabien COELHO wrote: > Patch applies cleanly, compiles, "make check" ok. > > I tried "\pset fieldsep_csv '\0'" which could be seen as one character, but > it does not want it. I'm okay with this behavior. > > I'd suggest to add a test about rejected

Re: csv format for psql

Bonjour Daniel, Currently popt->topt.fieldSepCsv can't be NULL so I've simplified this to just return pset_quoted_string(popt->topt.fieldSepCsv). Ok. While testing I found a small issue if "fieldsep_csv" is set to a strange value: \pset format_csv ',,' You meant \pset fieldsep_csv

Re: csv format for psql

Fabien COELHO wrote: > My point was more about the documentation which should be clear about what > is the EOL. I understand from your point above that the EOL is the > platform-specific one, which is yet again fine with me, but should be said > clearly in the documentation? Okay,

Re: csv format for psql

Bonjour Daniel, '\n' gets translated by libc when the output is in text mode. We discussed this upthread, but maybe it should be a code comment: added now. My point was more about the documentation which should be clear about what is the EOL. I understand from your point above that the EOL

Re: csv format for psql

Fabien COELHO wrote: > Doc: "according to the csv rules" -> "according to csv rules."? Fixed. > Doc: "RFC-4180" -> "RFC 4180"? Fixed. The other references to RFCs use this syntax indeed. > The previous RFC specifies CRLF as eol, but '\n' is hardcoded in the > source. I'm fine with

Re: csv format for psql

2018-08-10 12:25 GMT+02:00 Daniel Verite : > Pavel Stehule wrote: > > > > On the whole I'm inclined to resubmit the patch with > > > fieldsep_csv and some minor changes based on the rest > > > of the discussion. > > > > > > > +1 > > PFA an updated version. > Usage from the command line: >

Re: csv format for psql

Hello Daniel, PFA an updated version. Usage from the command line: $ psql --csv # or -P format=csv $ psql --csv -P fieldsep_csv=";" # for non-comma csv separator From inside psql: \pset format csv \pset fieldsep_csv '\t' Patch applies cleanly, compiles, global make check ok.

Re: csv format for psql

Pavel Stehule wrote: > > On the whole I'm inclined to resubmit the patch with > > fieldsep_csv and some minor changes based on the rest > > of the discussion. > > > > +1 PFA an updated version. Usage from the command line: $ psql --csv # or -P format=csv $ psql --csv -P

Re: csv format for psql

2018-06-03 19:16 GMT+02:00 David G. Johnston : > On Sunday, June 3, 2018, Pavel Stehule wrote: >> >> >> \pset fieldsep ; >> \pset format csv >> >> I don't like when one command overwrite settings of some other command. >> We can introduce some similar like GUC where default values from configure

Re: csv format for psql

On Sunday, June 3, 2018, Pavel Stehule wrote: > > > \pset fieldsep ; > \pset format csv > > I don't like when one command overwrite settings of some other command. We > can introduce some similar like GUC where default values from configure > file can be overwritten by custom setting for session.

Re: csv format for psql

Hi 2018-04-07 14:23 GMT+02:00 Daniel Verite : > Peter Eisentraut wrote: > > > Another thought: Isn't CSV just the same as unaligned output plus some > > quoting? Could we add a quote character setting and then define --csv > > to be quote-character = " and fieldsep = , ? > > Plus footer

Re: csv format for psql

2018-04-07 14:23 GMT+02:00 Daniel Verite : > Peter Eisentraut wrote: > > > Another thought: Isn't CSV just the same as unaligned output plus some > > quoting? Could we add a quote character setting and then define --csv > > to be quote-character = " and fieldsep

Re: csv format for psql

Daniel Verite wrote: > The output might still differ compared to COPY in that line endings > depend on the client-side OS. There's also the minor issue > of a single \ by itself on a line, which gets quoted by COPY > and not by psql. I meant \. or backslash followed by period. This

Re: csv format for psql

Isaac Morland wrote: > OK, mostly trying to avoid commenting because I doubt I have much to add. > But. If I ask for CSV and don't specify any overrides, I expect to get > "C"omma separated values, not some other character. More specifically, if I > say --csv I expect to get files that

Re: csv format for psql

Peter Eisentraut wrote: > Another thought: Isn't CSV just the same as unaligned output plus some > quoting? Could we add a quote character setting and then define --csv > to be quote-character = " and fieldsep = , ? Plus footer set to off. So --csv would be like \pset format unaligned

Re: csv format for psql

2018-04-07 13:55 GMT+02:00 Daniel Verite : > Pavel Stehule wrote: > > > so we can to have > > > > \pset format xxx > > > > and set of local possibly changed defaults > > > > \pset csv_fieldsep , > > \pset csv_tuplesonly on > > \pset unaligned_fieldsep | > > \pset

Re: csv format for psql

Pavel Stehule wrote: > so we can to have > > \pset format xxx > > and set of local possibly changed defaults > > \pset csv_fieldsep , > \pset csv_tuplesonly on > \pset unaligned_fieldsep | > \pset unaligned_tuplesonly off tuples_only (\t) is a single setting that is currently used by

Re: csv format for psql

Hi Pavel, > On Apr 6, 2018, at 1:38 AM, Pavel Stehule wrote: > > > > 2018-04-06 5:46 GMT+02:00 Jonathan S. Katz >: > > > On Apr 5, 2018, at 11:08 PM, Peter Eisentraut > > >

Re: csv format for psql

2018-04-06 5:46 GMT+02:00 Jonathan S. Katz : > > > On Apr 5, 2018, at 11:08 PM, Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> wrote: > > > > On 4/1/18 03:27, Pavel Stehule wrote: > >> I don't share option so CSV format should be exactly same like CSV COPY. > >> COPY

Re: csv format for psql

> On Apr 5, 2018, at 11:08 PM, Peter Eisentraut > wrote: > > On 4/1/18 03:27, Pavel Stehule wrote: >> I don't share option so CSV format should be exactly same like CSV COPY. >> COPY is designed for backups - and header is not too important there. >> When I

Re: csv format for psql

On 4/1/18 03:27, Pavel Stehule wrote: > I don't share option so CSV format should be exactly same like CSV COPY. > COPY is designed for backups - and header is not too important there. > When I seen some csv, then there usually header was used. I think in practice a lot of people use COPY also

Re: csv format for psql

2018-04-01 8:30 GMT+02:00 Fabien COELHO : > > Hello Isaac, > > Personnaly I do not have any problem with CSV defaulting to '|' separator, >>> given that anyway people often use anything but a comma for the purpose, >>> including '|'. >>> >>> However Pavel wants to block the

Re: csv format for psql

Hello Isaac, Personnaly I do not have any problem with CSV defaulting to '|' separator, given that anyway people often use anything but a comma for the purpose, including '|'. However Pavel wants to block the patch on this point. Too bad. OK, mostly trying to avoid commenting because I

Re: csv format for psql

On 31 March 2018 at 04:33, Fabien COELHO wrote: > > Bonjour Daniel, > > For csv, Fabien and Peter expressed the opinion that we shouldn't >> create another fieldsep-like variable specifically for it, but instead >> reuse fieldsep. That's what my latest patch does. >> >> Now

Re: csv format for psql

On 31/03/18 21:33, Fabien COELHO wrote: Bonjour Daniel, For csv, Fabien and Peter expressed the opinion that we shouldn't create another fieldsep-like variable specifically for it, but instead reuse fieldsep. That's what my latest patch does. Now it turns out that sharing fieldsep comes with

Re: csv format for psql

Bonjour Daniel, For csv, Fabien and Peter expressed the opinion that we shouldn't create another fieldsep-like variable specifically for it, but instead reuse fieldsep. That's what my latest patch does. Now it turns out that sharing fieldsep comes with some problems. Personnaly I do not

Re: csv format for psql

2018-03-30 0:15 GMT+02:00 David G. Johnston : > On Thu, Mar 29, 2018 at 7:30 AM, Daniel Verite > wrote: > >> Personally I think the benefit of sharing fieldsep is not worth these >> problems, but I'm waiting for the discussion to continue with

Re: csv format for psql

On Thu, Mar 29, 2018 at 7:30 AM, Daniel Verite wrote: > Personally I think the benefit of sharing fieldsep is not worth these > problems, but I'm waiting for the discussion to continue with > more opinions. ​Apologies in advance if I mis-represent someone's position.​

Re: csv format for psql

David G. Johnston wrote: > Unaligned format could grow its own fieldsep if it wanted to but it can > also just use the default provided fieldsep var whose default value is > pipe. If it did grow one it would need to understand "not set" in order to > preserve existing behavior. We don't

Re: csv format for psql

Isaac Morland wrote: > The actual reason I'm posting this is because some of the discussion has > made me a bit confused: there is already a CSV format defined for the COPY > command and used by the psql \copy. I just want to check that what is being > discussed here would use the exact

Re: csv format for psql

2018-03-29 14:17 GMT+02:00 Daniel Verite : > David G. Johnston wrote: > > > Or, really, just make --csv take an optional argument which, if present, > is > > the delimiter. > > I don't think psql can support optional arguments because > psql --option foo > would

Re: csv format for psql

David G. Johnston wrote: > Or, really, just make --csv take an optional argument which, if present, is > the delimiter. I don't think psql can support optional arguments because psql --option foo would be ambiguous, since foo could be the option's value or the name of a database to

Re: csv format for psql

David G. Johnston wrote: > Could someone post how captions, rows-only, and footer pset settings factor > into this? Specifically are they fixed to on/off or will they hide/show if > users request them explicitly? This is described in the doc with: + csv format writes columns

Re: csv format for psql

On Wed, Mar 28, 2018 at 4:19 PM, Isaac Morland wrote: > On 28 March 2018 at 15:43, Joshua D. Drake wrote: > >> On 03/28/2018 12:35 PM, David G. Johnston wrote: >> >> I like to call it "Character Separated Values" now for just that reason. >> >>

Re: csv format for psql

On 28 March 2018 at 15:43, Joshua D. Drake wrote: > On 03/28/2018 12:35 PM, David G. Johnston wrote: > > I like to call it "Character Separated Values" now for just that reason. > > > Isn't the actual wording Character Delimited Values? I may be picking at > hairs here

Re: csv format for psql

On Wednesday, March 28, 2018, Fabien COELHO wrote: > > > And if we introduce csv-specific fieldsep, then we multiply this wrong >> design. The fix in this direction is renaming fieldsep to fieldsep-unaliagn >> - but it is probably too big change too. So this design is

Re: csv format for psql

On 03/28/2018 12:35 PM, David G. Johnston wrote: On Monday, March 26, 2018, Daniel Verite > wrote: We could even support only the comma and make it non-configurable based on the fact it's Comma-Separated-Values, not

Re: csv format for psql

On Monday, March 26, 2018, Daniel Verite wrote: > > We could even support only the comma and make it non-configurable > based on the fact it's Comma-Separated-Values, not > Whatever-Separated-Values, except that won't do much > to serve the users interests, as the

Re: csv format for psql

On Wednesday, March 28, 2018, David G. Johnston wrote: > On Wednesday, March 28, 2018, Pavel Stehule > wrote: > >> >> Are there some possible alternatives? >>> >>> Given the date and the fact that the cf end is 3 days away, the proposed

Re: csv format for psql

On Wednesday, March 28, 2018, Pavel Stehule wrote: > > Are there some possible alternatives? >>> >> >> Given the date and the fact that the cf end is 3 days away, the proposed >> short term alternative is Daniel's version, that I feel is reasonable. Ok, >> people have to

Re: Re: csv format for psql

2018-03-28 10:24 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > I'd like to convince you to compromise, because otherwise I'm afraid we >>> will not get this feature. >>> >> >> [...] >> >>> >>> The only no-surprise, no-behavioral-change, alternative I see is to have >>> a >>>

Re: Re: csv format for psql

2018-03-27 11:35 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > I'd like to convince you to compromise, because otherwise I'm afraid we > will not get this feature. > > 1. use special default string for formats that doesn't field sep - like >>> "not used" or some 2.

Re: Re: csv format for psql

Hello Pavel, I'd like to convince you to compromise, because otherwise I'm afraid we will not get this feature. 1. use special default string for formats that doesn't field sep - like "not used" or some 2. I can implemet the option fieldsep_default - very similary to fieldsep_zero to reset

Re: Re: csv format for psql

2018-03-26 20:26 GMT+02:00 Daniel Verite : > Pavel Stehule wrote: > > > b) the list of pset options is bloating - every possible new format can > > introduce fieldsep_X option > > What new format? > The usefulness of fieldsep does not extend outside of xSV, and

Re: Re: csv format for psql

Pavel Stehule wrote: > b) the list of pset options is bloating - every possible new format can > introduce fieldsep_X option What new format? The usefulness of fieldsep does not extend outside of xSV, and it's no suprise that there have been no other use for a fieldsep-like variable

Re: Re: csv format for psql

2018-03-26 14:44 GMT+02:00 Daniel Verite : > Pavel Stehule wrote: > > > implemented in attached patch > > Consider your initial output of \pset, when no option is specified > = > $ ./psql > psql (11devel) > Type "help" for help. > > postgres=#

Re: Re: csv format for psql

Pavel Stehule wrote: > implemented in attached patch Consider your initial output of \pset, when no option is specified = $ ./psql psql (11devel) Type "help" for help. postgres=# \pset border 1 columns 0 expanded off

Re: Re: csv format for psql

2018-03-25 18:02 GMT+02:00 Pavel Stehule : > > > 2018-03-25 15:21 GMT+02:00 Fabien COELHO : > >> >> >> Hello Pavel, >> >> [...] >>> it is correct. Default format is aligned, that doesn't use fieldsep. >>> >> >> My comment is that currently

Re: Re: csv format for psql

2018-03-25 15:21 GMT+02:00 Fabien COELHO : > > > Hello Pavel, > > [...] >>> >> it is correct. Default format is aligned, that doesn't use fieldsep. >> > > My comment is that currently fieldsep is kind of a variable, the value of > which is displayed and reliable wrt commands

Re: Re: csv format for psql

2018-03-24 10:06 GMT+01:00 Fabien COELHO : > > Hello Pavel, > > I'm suggesting to add \csv which would behave like \H to toggle CSV mode so as to improve this situation, with a caveat which is that toggling back \csv would have forgotted the previous

Re: Re: csv format for psql

Hello Pavel, I'm suggesting to add \csv which would behave like \H to toggle CSV mode so as to improve this situation, with a caveat which is that toggling back \csv would have forgotted the previous settings (just like \H does, though, so would for instance reset to aligned

Re: Re: csv format for psql

minor fix > all is working now [pavel@nemesis postgresql]$ psql --csv -F ';' -c "table foo" postgres a;b;c 3;4;Nazdar 3;4;Nazdar [pavel@nemesis postgresql]$ psql -F ';' --csv -c "table foo" postgres a;b;c 3;4;Nazdar 3;4;Nazdar [pavel@nemesis postgresql]$ psql --csv -c "table foo" postgres

Re: Re: csv format for psql

2018-03-24 8:24 GMT+01:00 Pavel Stehule : > > > 2018-03-24 8:15 GMT+01:00 Fabien COELHO : > >> >> Hello Pavel, >> >> The patch adds a simple way to generate csv output from "psql" queries, much simpler than playing around with COPY or \copy. It

Re: Re: csv format for psql

2018-03-24 8:15 GMT+01:00 Fabien COELHO : > > Hello Pavel, > > The patch adds a simple way to generate csv output from "psql" queries, >>> much simpler than playing around with COPY or \copy. It allows to >>> generate >>> a clean CSV dump from something as short as: >>> >>>

Re: Re: csv format for psql

Hello Pavel, The patch adds a simple way to generate csv output from "psql" queries, much simpler than playing around with COPY or \copy. It allows to generate a clean CSV dump from something as short as: sh> psql --csv -c 'TABLE foo' > foo.csv Documentation is clear. Test cover a

Re: Re: csv format for psql

2018-03-23 18:55 GMT+01:00 Fabien COELHO : > > Hello Daniel, > > Do you know when you'll have an updated patch that addresses the minor >>> issues brought up in review and the concern above? >>> >> >> Here's an update addressing the issues discussed: >> >> -

Re: Re: csv format for psql

2018-03-23 12:59 GMT+01:00 Daniel Verite : > Pavel Stehule wrote: > > > It should not be hard. All formats can has '|' like now, and csv can > have a > > ',' - then if field separator is not explicit, then default field > separator > > is used, else specified

Re: Re: csv format for psql

Hello Daniel, Do you know when you'll have an updated patch that addresses the minor issues brought up in review and the concern above? Here's an update addressing the issues discussed: - fieldsep and recordsep are used, no more fieldsep_csv - the command line option is --csv without short

Re: Re: csv format for psql

Pavel Stehule wrote: > It should not be hard. All formats can has '|' like now, and csv can have a > ',' - then if field separator is not explicit, then default field separator > is used, else specified field separator is used. > > You can see my idea in attached patch With that patch,

Re: Re: csv format for psql

2018-03-22 20:10 GMT+01:00 Pavel Stehule : > > > 2018-03-22 19:28 GMT+01:00 Pavel Stehule : > >> >> >> 2018-03-22 18:38 GMT+01:00 Fabien COELHO : >> >>> >>> Hello Pavel, >>> >>> Using \pset format csv means overwriting field

Re: Re: csv format for psql

2018-03-22 19:28 GMT+01:00 Pavel Stehule : > > > 2018-03-22 18:38 GMT+01:00 Fabien COELHO : > >> >> Hello Pavel, >> >> Using \pset format csv means overwriting field sep every time - nobody >>> uses >>> | >>> >> >> Yep. The alternative is to have a

Re: Re: csv format for psql

2018-03-22 18:38 GMT+01:00 Fabien COELHO : > > Hello Pavel, > > Using \pset format csv means overwriting field sep every time - nobody uses >> | >> > > Yep. The alternative is to have a csv-specific separator variable, which > does not seem very useful, must be remembered,

Re: Re: csv format for psql

Hello Pavel, Using \pset format csv means overwriting field sep every time - nobody uses | Yep. The alternative is to have a csv-specific separator variable, which does not seem very useful, must be remembered, but this is indeed debatable. I think so dependency on order of psql

Re: Re: csv format for psql

Hi 2018-03-22 16:30 GMT+01:00 Daniel Verite : > David Steele wrote: > > > Do you know when you'll have an updated patch that addresses the minor > > issues brought up in review and the concern above? > > Here's an update addressing the issues discussed: > > -

Re: Re: csv format for psql

David Steele wrote: > Do you know when you'll have an updated patch that addresses the minor > issues brought up in review and the concern above? Here's an update addressing the issues discussed: - fieldsep and recordsep are used, no more fieldsep_csv - the command line option is --csv

Re: Re: csv format for psql

Hi Daniel, On 3/10/18 1:49 AM, Fabien COELHO wrote: > >>> recordsep in the unaligned mode doesn't play the role of a line ending >>> because the last line is not finished by recordsep. According to the >>> source >>> code, this is intended, see print_unaligned_text() in print.c: >> >> Something

Re: csv format for psql

recordsep in the unaligned mode doesn't play the role of a line ending because the last line is not finished by recordsep. According to the source code, this is intended, see print_unaligned_text() in print.c: Something else comes to mind: CSV allows linefeeds inside fields, and we don't want

Re: csv format for psql

Hello Daniel, About "-C", I'm fine if it is used and if it is not used, really. psql begins to be quite full of one letter options, currently 34 of them, with upper & lower cases and numbers included. The solution to set fieldsep automatically to ',' with \pset format csv is problematic.

Re: csv format for psql

On Fri, Mar 9, 2018 at 3:18 PM, Daniel Verite wrote: > I think that the point of recordsep in unaligned mode is you can set it > to something that never appears in the data, especially when embedded > newlines might be in the data. In CSV this is solved differently so >

  1   2   >