On 24.04.23 03:18, Tom Lane wrote:
I wouldn't actually *use* pchomp here, because that induces an
unnecessary
copy of the result string. I had in mind more like copying pchomp's code
to count up the trailing newline(s) and then pass a corrected length
to cstring_to_text_with_len.
Changed.
Jim Jones writes:
> If we agree to remove it, the change wouldn't be substantial :) I guess
> we could just pchomp it in the end of the function, as suggested by Tom.
> Attached a draft patch.
I wouldn't actually *use* pchomp here, because that induces an unnecessary
copy of the result string.
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
On Sun, 23 Apr 2023 at 12:28, Pavel Stehule wrote:
>
>
> Dne ne 23. 4. 2023 18:03 uživatel Isaac Morland
> napsal:
>
>> On Sun, 23 Apr 2023 at 10:52, Tom Lane wrote:
>>
>>> Isaac Morland writes:
>>>
>>
>>
>>> > I might go so
>>> > far as to change the psql display routines to not leave a
Dne ne 23. 4. 2023 18:03 uživatel Isaac Morland
napsal:
> On Sun, 23 Apr 2023 at 10:52, Tom Lane wrote:
>
>> Isaac Morland 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.
On Sun, 23 Apr 2023 at 10:52, Tom Lane wrote:
> Isaac Morland 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
Isaac Morland writes:
> That being said, this is a database column result and I agree it would look
> more elegant if the blank line in the display were not there.
Yeah, that would basically be the argument for editorializing on libxml2's
result. It's a weak argument, but not entirely without
ne 23. 4. 2023 v 16:48 odesílatel Tom Lane napsal:
> Jim Jones writes:
> > On 23.04.23 07:31, Pavel Stehule wrote:
> >> Looks so there is an extra empty row.
>
> > Good catch! It looks like it comes directly from libxml2.
>
> Is it really a bug? If libxml2 itself is putting in that newline,
>
ne 23. 4. 2023 v 14:42 odesílatel Isaac Morland
napsal:
> On Sun, 23 Apr 2023 at 01:31, Pavel Stehule
> wrote:
>
>> Hi
>>
>> maybe I found a bug in xmlserialize
>>
>> SELECT xmlserialize(DOCUMENT '42'
>> AS varchar INDENT);
>>
>> (2023-04-23 07:27:53) postgres=# SELECT xmlserialize(DOCUMENT
>>
Jim Jones writes:
> On 23.04.23 07:31, Pavel Stehule wrote:
>> Looks so there is an extra empty row.
> Good catch! It looks like it comes directly from libxml2.
Is it really a bug? If libxml2 itself is putting in that newline,
I'm not sure we should take it on ourselves to strip it.
> I'll do
On Sun, 23 Apr 2023 at 01:31, Pavel Stehule wrote:
> Hi
>
> maybe I found a bug in xmlserialize
>
> SELECT xmlserialize(DOCUMENT '42'
> AS varchar INDENT);
>
> (2023-04-23 07:27:53) postgres=# SELECT xmlserialize(DOCUMENT
> '42' AS varchar INDENT);
> ┌─┐
> │
> On Sun, Apr 23, 2023 at 02:02:17PM +0200, Jim Jones wrote:
> On 23.04.23 07:31, Pavel Stehule wrote:
> > Hi
> >
> > maybe I found a bug in xmlserialize
> >
> > SELECT xmlserialize(DOCUMENT '42'
> > AS varchar INDENT);
> >
> > (2023-04-23 07:27:53) postgres=# SELECT xmlserialize(DOCUMENT
> > '42'
On 23.04.23 07:31, Pavel Stehule wrote:
Hi
maybe I found a bug in xmlserialize
SELECT xmlserialize(DOCUMENT 'x="y">42' AS varchar INDENT);
(2023-04-23 07:27:53) postgres=# SELECT xmlserialize(DOCUMENT
'42' AS varchar INDENT);
┌─┐
│ xmlserialize │
Hi
maybe I found a bug in xmlserialize
SELECT xmlserialize(DOCUMENT '42' AS
varchar INDENT);
(2023-04-23 07:27:53) postgres=# SELECT xmlserialize(DOCUMENT
'42' AS varchar INDENT);
┌─┐
│ xmlserialize │
╞═╡
│ ↵│
│
14 matches
Mail list logo
