Andrew Dunstan <and...@dunslane.net> writes: > On 01/04/2012 01:13 PM, Tom Lane wrote: >> Not entirely sure what to do about this. We could consider reverting >> the aforesaid patch and trying to find another way of fixing that code's >> failure to cope with standard-conforming strings, but I'm not sure that >> there's a good way to know whether standard_conforming_strings is active >> here, and anyway that code was ugly as sin and I'd rather not resurrect >> it. But on the other hand, there are no clear line boundaries in the >> compressed data, and we can't introduce any without (a) worsening >> compression and (b) breaking compatibility with existing dump files. >> >> Anybody have any bright ideas? I'm fresh out at the moment.
> I pondered this while out on my daily constitutional. The first thing > that occurred to me is that it would possibly have been better if we'd > made pg_dump not use a quoting mechanism whose behaviour is dependent on > a setting (e.g. E'' or dollar quoting). But I guess that's water under > the bridge. > Could we detect an appropriate line ending in ahwrite() after it's been > decompressed and buffer partial lines accordingly? Not easily: there could be newlines embedded in data strings or SQL identifiers. I'm not seeing any way around this except to restore the minimal lexing capability. One thing we could probably do is to restrict it to be used only when reading table data, and continue to assume that object creation commands can be emitted as-is. That would at least get us out of needing to parse dollar-quoted literals, which aren't used in the INSERT commands. But we'd have to deal with standard-conforming strings some way. The idea I had about that, since we have an open database connection at hand, is to check the connected backend's standard_conforming_strings state via PQparameterStatus. If it doesn't have the right setting then things are going to fail anyway. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers