On 28 January 2013 20:40, Pavel Stehule <pavel.steh...@gmail.com> wrote: > 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.
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
