Stephen Frost <sfrost@snowman.net> writes:
> I'd be happy to work this up, and I think it would work, but it seems
> kind of ugly since then we'd have ahwrite and ahprintf returning error
> codes which in 99% of the cases wouldn't be checked which doesn't seem
> terribly clean. :/
I agree. I wonder if it wouldn't be cleaner to pass the information in
the other direction, ie, send a boolean down to PrintTocData saying "you
are sending SQL commands" or "you are sending COPY data". Then, instead
of depending only on the libpq state to decide what to do in
ExecuteSqlCommandBuf, we could cross-check: if we're sending SQL data
and the libpq state is wrong, just discard the line.
The immediate problem you saw is fairly clear at this point:
ExecuteSqlCommandBuf and its subroutines attempt to parse the data well
enough to determine command boundaries (if SQL commands) or line
boundaries (if COPY data). If they are misinformed about what they are
processing then the parsing gets totally confused --- it's not hard to
imagine the code thinking the entire COPY dump is an incomplete SQL
command. So driving this from an upper-level indication of what we are
currently sending, rather than libpq status, ought to be more robust.
BTW, we'd not need to mess with a ton of routine APIs to make this
happen --- just add a flag in ArchiveHandle.
regards, tom lane