On Wed, Oct 16, 2024, at 18:04, Jacob Champion wrote: > A hypothetical type whose text representation can contain '\r' but not > '\n' still can't be unambiguously round-tripped under this scheme: > COPY FROM will see the "mixed" line endings and complain, even though > there's no ambiguity.
Yeah, that's quite an ugly limitation. > Maybe no one will run into that problem in practice? But if they did, > I think that'd be a pretty frustrating limitation. It'd be nice to > override the behavior, to change it from "do what you think I mean" to > "do what I say". That would be nice. >> That's an interesting idea that would provide more flexibility, >> though, at the cost of complicating things by overloading the meaning >> of DELIMITER. > > I think that'd be a docs issue rather than a conceptual one, though... > it's still a delimiter. I wouldn't really expect end-user confusion. Yeah, I meant the docs, but that's probably fine, we could just add <note> to DELIMITER. >> What I found appealing with the idea of a new COPY format, >> was that instead of overloading the existing options >> with more complexity, a new format wouldn't need to affect >> the existing options, and the new format could be explained >> separately, without making things worse for users not >> using this format. > > I agree that we should not touch the existing formats. If > RAW/SINGLE/whatever needed a multibyte line delimiter, I'm not > proposing that the other formats should change. Right, I didn't think you did either, I meant overloading the existing options, from a docs perspective. But I agree it's probably fine if we just overload DELIMITER in the docs, that should be possible to explain in a pedagogic way, without causing confusion. /Joel
