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

Поиск
Список
Период
Сортировка
От Dean Rasheed
Тема Re: Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used
Дата
Msg-id CAEZATCUNJuac-Dur_Vsi5V-4NYHS2FDKBuxAff-vhV83DcwBrw@mail.gmail.com
обсуждение исходный текст
Ответ на 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>)
Ответы Re: Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 28 January 2013 20:40, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 2013/1/28 Dean Rasheed <dean.a.rasheed@gmail.com>:
>> On 28 January 2013 17:32, Stephen Frost <sfrost@snowman.net> wrote:
>>> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>>>> Both.  If we had done this when we first implemented format(), it'd be
>>>> fine, but it's too late to change it now.  There very likely are
>>>> applications out there that depend on the current behavior.  As Dean
>>>> says, it's not incompatible with SUS, just a superset, so ISTM this
>>>> patch is proposing to remove documented functionality --- for no very
>>>> strong reason.
>>>
>>> It's only a "superset" of the very poor subset of printf()-like
>>> functionality that we currently support through the format() function.
>>>
>>> If we can actually match glibc/SUS (which I don't believe the initial
>>> patch did..) and support a mix of explicitly specified arguments and
>>> implicit arguments, along with the various width, precision, and other
>>> format specifications, then fine by me.
>>>
>>> I'm not convinced that's actually possible due to the ambiguity which
>>> will certainly arise and I'm quite sure the documentation that explains
>>> what we do in each case will deserve it's own chapter.
>>>
>>
>> There are a number of separate issues here, but I don't see this as an
>> intractable problem. In general a format specifier looks like:
>>
>> %[parameter][flags][width][.precision][length]type
>>
>> parameter - an optional n$. This is where we have implemented a
>> superset of the SUS printf(). But I think it is a useful superset, and
>> it's too late to remove it now. Any ambiguity lies here, where we go
>> beyond the SUS - some printf() implementations appear to do something
>> different (apparently without documenting what they do). I think our
>> documentation could be clearer here, to explain how mixed parameters
>> are handled.
>>
>> flags - not currently implemented. Pavel's second patch adds support
>> for the '-' flag for left justified string output. However, I think
>> this should support all datatypes (i.e., %I and %L as well as %s).
>
> no - surely not - I% and L% is PostgreSQL extension and left or right
> alignment is has no sense for PostgreSQL identifiers and PostgreSQL
> literals.

Left/right alignment and padding in printf() apply to all types, after
the data value is converted to a string. Why shouldn't that same
principle apply to %I and %L? The obvious use-case is for producing
tabular output of data with columns neatly aligned. If we don't
support %I and %L then any alignment of columns to the right is lost.

Regards,
Dean



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used