2013/1/28 Dean Rasheed <dean.a.rash...@gmail.com>: > On 28 January 2013 17:32, Stephen Frost <sfr...@snowman.net> wrote: >> * Tom Lane (t...@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. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers