On 2023-Oct-17, Dominique Devienne wrote:
> But then on Parse, the query text, which also contains embedded
> newlines but also embedded double-quotes, for column aliases, or table
> names, or whatever, even why not a single char literal like '"' (i.e.
> single-quote, double-quote, single-quote), seems to be double-quoted
> only. So how am I supposed to know when the SQL ends?
Yeah, I've never heard of anybody trying to machine-parse these lines,
so if those points are not addressed in the trace output, that probably
explains why. It would probably be a good idea to change that. This
stuff is relatively new, and most likely has thus far only used by
visual inspecting the contents of the trace file (at least that's how
*I* have used them), and only with very simple dummy queries.
Bummer... In fact, I'm not a fan of the whole FILE* based API,
I'd have preferred a callback based API where I decide what to do with
the message, w/ info about which connection the tracing is for, so I can
safely multiplex concurrent connections (from the same process) to the
same file for example. Or log thread-related information too. Or decide
to split high level info from large row-info from a GB-sized COPY, possibly
keeping only the high level one.
The doc doesn't mention where using the same file for several concurrent
connections is safe or not. When things are flushed or not. Whether I can insert
my own lines on that FILE*, w/o interspacing them with the fwrite()s from libpq.
So, patches welcome, I guess.
I often dump trace files to SQLite for analysis, in full or in part.
That's my main reason for wanting to machine parse those files.
I can of course use some heuristics to work-around the multi-line Parse lines,
but I'm not a fan of brittle code, and I'm surprised tracing's output is not more consistent and always line based.
I'm not a LibPQ or PostgreSQL dev I'm afraid, so not likely to provide any.
Merely a user of both. Thanks for the input Alvaro. --DD