Re: Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used - Mailing list pgsql-hackers

From Dean Rasheed
Subject Re: Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used
Date
Msg-id CAEZATCXAYkQxVqaTmGvnxaLGSN2egfYtDxbrQE_GKyo_3-mLSA@mail.gmail.com
Whole thread Raw
In response to Re: Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
On 9 February 2013 18:30, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>>>> There are a new question
>>>>
>>>> what should be result of
>>>>
>>>> format(">>%2$*1$s<<", NULL, "hello")
>>>>
>>>> ???
>>
>> My first thought is that a NULL width should be treated the same as no
>> width at all (equivalent to width=0), rather than raising an
>> exception.
>>
>>> minor update - fix align NULL for %L
>>
>> You need to do the same for a NULL value with %s, which currently
>> produces an empty string regardless of the width.
>
> have others same opinion? Usually I don't like hide NULLs, but this is
> corner case (and specific function) and I have not strong opinion on
> this issue.
>

One use case for this might be something like

SELECT format('%*s', minimum_width, value) FROM some_table;

Throwing an exception when minimum_width is NULL doesn't seem
particularly useful. Intuitively, it just means that row has no
minimum width, so I think we should allow it.

I think the case where the value is NULL is much more clear-cut.
format('%s') produces '' (empty string). So format('%3s') should
produce '   '.


>>
>> The documentation also needs to be updated. I'm thinking perhaps
>> format() should now have its own separate sub-section in the manual,
>> rather than trying to cram it's docs into a single table row. I can
>> help with the docs if you like.
>
> please, if you can, write it. I am sure, so you do it significantly
> better than me.
>

Here is my first draft. I've also attached the generated HTML page,
because it's not so easy to read an SGML patch.

Regards,
Dean

Attachment

pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Department of Redundancy Department: makeNode(FuncCall) division
Next
From: Yeb Havinga
Date:
Subject: Re: JSON NULLs