Re: Re: csv format for psql - Mailing list pgsql-hackers

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
>> csv-specific fieldsep. I'm not keen on that one because it is yet another
>> variable, one has to remember it, and then it asks the question about
>> recordsep... and I think there are already too many parameters, and more is
>> not desirable, although I probably could live with that if I can live with
>> "fieldsep_zero":-)
>>
>>
> I don't share your opinion so introduction csv-specific fieldsep is
> surprise less. Current design is wrong - this thread is a evidence.

Wrong is too strong a word. Current design is not perfect, sure. Proposed 
alternatives are somehow worse, at least to some people mind, which 
explains why we arrived on this version after a few iterations.

> 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 nothing what I can mark as good solution.

Good, we somehow agree on something!

> I can live with because it is much better than using pipe as separator 
> for csv, and because real impact is small - for almost people it will be 
> invisible - but have not good feeling from it.

> 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 do two pset to get comma-separated csv, otherwise they get 
pipe-separated csv in one pset.

You could compromise on that for now, and submit an improvement patch for 
a later version if you wish.

Otherwise, ISTM that the current result of this thread is that there will 
be no simple CSV in pg11:-(

Or maybe I can mark Daniel's latest version as "ready" and point out that 
there is some disagreement on the thread, so it is not a full consensus. 
Then a committer can decide whether it is better in like that or that it 
should be put back in some design stage, possibly with their preference 
wrt to the kind of solution they think best.

-- 
Fabien.