From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used |
Date: | 2013-02-10 12:37:07 |
Message-ID: | CAFj8pRAxhDRua1KOxdyjekjuhv7XaczKKfXta5JbQY9JfCaHTQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2013/2/10 Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>:
> On 9 February 2013 18:30, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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 ' '.
>
ok - in this case I can accept NULL as "ignore width"
>
>>>
>>> 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.
>
nice
I have only one point - I am think, so format function should be in
table 9-6 - some small text with reference to special section.
Regards
Pavel
> Regards,
> Dean
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2013-02-10 15:03:40 | Re: JSON NULLs |
Previous Message | Magnus Hagander | 2013-02-10 11:03:57 | Re: Fwd: Successful post to pgsql-hackers |