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

2013/1/28 Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>:
> On 28 January 2013 17:32, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)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.

Regards

Pavel

>
> width - not currently implemented. Pavel's second patch adds support
> for this, but note that for full compatibility with the SUS it needs
> to also support widths specified using * and *n$. Also, I think it
> should support all supported datatypes, not just strings.
>
> precision - only relevant to numeric datatypes, which we don't support.
>
> length - only relevant to numeric datatypes, which we don't support.
>
> type - this is where we only support a small subset of the SUS (plus a
> couple of SQL-specific types). I'm not sure if anyone has any plans to
> extend this, but that's certainly not on the cards for 9.3.
>
>
> So the relevant pieces that Pavel's second patch is attempting to add
> support for are the '-' flag and the width field. As noted above,
> there are a couple of areas where the current patch falls short of the
> SUS:
>
> 1). The '-' flag and width field are supposed to apply to all types. I
> think that not supporting %I and %L will be somewhat limiting, and
> goes against the intent of the SUS, even though those types are
> PostgreSQL extensions.
>
> 2). The width field is supposed to support * (width specified by the
> next function argument) and *n$ (width specified by the nth function
> argument). If we supported this, then we could claim full
> compatibility with the SUS in all fields except for the type support,
> which would seem like a real step forward.
>
> Regards,
> Dean