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

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).

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