Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> On 26/08/10 22:16, Tom Lane wrote:
>> I think this is likely to break apps that have worked for years. I
>> can't get excited about doing that in return for an "0-10%" speedup
>> that might only materialize on some platforms. If the numbers were
>> better, it'd be worth paying that price, but ...
> Ok. If we have to, we can keep that, it just requires more programming.
> After searching for a \n, we can peek at the previous byte to check if
> it's a backslash (and if it is, the one before that to see if it's a
> backslash too, and so forth until we find a non-backslash).
I seem to recall that this same problem was discussed before, and we
concluded that you couldn't reliably parse backwards to figure out
whether the newline was backslashed. Although that might have been
in the context of data still in client encoding, where you have the
extra frammish that a "backslash" could be a non-first byte of a
character. Anyway it'd be a good idea to recheck those old discussions
if you can find 'em.
Another approach that came to me was to parse forwards, and if we find
a backslash at the end of the line, then conclude that we had a
backslashed newline and slurp in another line's worth of data at that
time. I'm not sure how much restructuring would be needed to make that
feasible, but it seems worth considering.
regards, tom lane