Conversation
|
The multi-line queries are harder to parse in logs, but far more readable in source. Perhaps there is a |
|
Hello Eric,
Right, I understand source readability, but as I pointed-out in the PR description, some other queries are single-line in the code, and not super readable. My PR is not "breaking everything", just making things consistent.
The goal is not as much "machine log parsing" as general elegance. A good general log parser will have to deal with multi-line queries sooner or later as devs are likely to like them. IMHO, dba tooling should aim at minimizing dba pains, hence my current suggestion. I could come-up with a solution which would take a multi-line query in code, pass it through Cheers, J-F |
|
Certainly things are not consistent. If consistency is the goal, I'd favour making things consistent for human readability, but this would be a style choice, not a technical choice. Perhaps something like this would be easy to parse by machines and also easy to read by devs: |
I would down-vote this suggestion. It makes it impossible to cut-and paste the query for testing in a shell. So IMHO, this new style suggestion is worse than the two styles already present in the code. |
|
Then yes, your earlier suggestion of a processing step (suggested as a sed command, but could as you say be in the code), seems more attractive to me. Your mileage may vary. |
In the code, some queries are single line (example below)...
..and some others are multi-line (example below).
The multi-line queries generate harder to parse general logs, and IMHO are sub-optimal.
This PR removes all the multi-line queries I found (I might have missed some).
(I also simplified a query removing
AS, from what I saw, they were not eneded)