Re: xmlserialize bug - extra empty row at the end

On Sun, 23 Apr 2023 at 12:28, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:

>
>
> Dne ne 23. 4. 2023 18:03 uživatel Isaac Morland <isaac(dot)morland(at)gmail(dot)com>
> napsal:
>
>> On Sun, 23 Apr 2023 at 10:52, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>>> Isaac Morland <isaac(dot)morland(at)gmail(dot)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.
>