Re: xmlserialize bug - extra empty row at the end - Mailing list pgsql-hackers
| From | Isaac Morland |
|---|---|
| Subject | Re: xmlserialize bug - extra empty row at the end |
| Date | |
| Msg-id | CAMsGm5e1BN4qYEYgdX++UcUKSCMSDLVbC11F3eSr1yHmneizhg@mail.gmail.com Whole thread Raw |
| In response to | Re: xmlserialize bug - extra empty row at the end (Pavel Stehule <pavel.stehule@gmail.com>) |
| Responses |
Re: xmlserialize bug - extra empty row at the end
|
| List | pgsql-hackers |
On Sun, 23 Apr 2023 at 12:28, Pavel Stehule <pavel.stehule@gmail.com> wrote:
Dne ne 23. 4. 2023 18:03 uživatel Isaac Morland <isaac.morland@gmail.com> napsal:On Sun, 23 Apr 2023 at 10:52, Tom Lane <tgl@sss.pgh.pa.us> wrote:Isaac Morland <isaac.morland@gmail.com> writes:> I might go so
> far as to change the psql display routines to not leave a blank line after
> the content in the event it ends with a newline.
psql has *no* business changing what it displays: if what came from the
server has a trailing newline, that had better be made visible. Even if
we thought it was a good idea, it's about 25 years too late to reconsider
that. However, xmlserialize()'s new indenting behavior isn't set in
stone yet, so we could contemplate chomping newlines within that.The trailing newline is made visible by the little bent arrow character that appears at the right hand side. So you could still tell whether the value ended with a trailing newline. I agree that simply dropping the trailing newline before displaying the value would be a very bad idea.What is benefit or usage of this trailing newline?
When creating a text file, it is conventional to end it with a newline. Every single line of the file is ended with a newline, including the last line of a file. Various tools deal with text files which are missing the newline on the last line in various ways depending on context. If you "cat" a file which is missing its trailing newline, the command prompt naturally ends up on the same line of the display as the characters after the last newline. Tools like “less” often adjust their display so the presence or absence of the trailing newline makes no difference.
So it’s not so much about benefit or usage, it’s about what text files normally contain. Newline characters are used as line terminators, not line separators.
Of course, it's conventional for a database value not to end with a newline. If I store a person's name in the database, it would be weird to append a newline to the end. Here we have serialized XML which we tend to think of storing in a text file — where one would expect it to end with a newline — but we're displaying it in a table cell as part of the output of a database query, where one typically does not expect values to end with a newline (although they can, and psql displays values differently even if they differ only in the presence or absence of a newline at the end).
If you were to load a typical text file into a column of a database row and display it using psql, you would see the same phenomenon.
My inclination would be, if we're just calling to a long-standardized library routine, to just accept its output as is. If a program is saving the output to a text file, that would be the expected behaviour. If not, then we need to document that the output of our function is the output of the library function, minus the trailing newline.
Personally, when I do some formatting I prefer adding newlines on client side before necessity of removing.
pgsql-hackers by date: