2013/1/29 Dean Rasheed <dean.a.rash...@gmail.com>: > On 28 January 2013 20:32, Dean Rasheed <dean.a.rash...@gmail.com> wrote: >> In general a format specifier looks like: >> >> %[parameter][flags][width][.precision][length]type >> > > This highlights another problem with the current implementation --- > the '-' flag and the width field need to be parsed separately. So > '%-3s' should be parsed as a '-' flag followed by a width of 3, not as > a width of -3, which is then interpreted as left-aligned. This might > seem like nitpicking, but actually it is important: > > * In the future we might support more flags, and they can be specified > in any order, so the '-' flag won't necessarily come immediately > before the width. > > * The width field is optional, even if the '-' flag is specified. So > '%-s' is perfectly legal and should be interpreted as '%s'. The > current implementation treats it as a width of 0, which is wrong. > > * The width field might not be a number, it might be something like * > or *3$. Note that the SUS allows a negative width to be passed in as a > function argument using this syntax, in which case it should be > treated as if the '-' flag were specified.
A possibility to specify width as * can be implemented in future. The format() function was not designed to be fully compatible with SUS - it is simplified subset with pg enhancing. There was a talks about integration to_char() formats to format() and we didn't block it - and it was reason why I proposed and pushed name "format" and not "printf", because there can be little bit different purposes than generic printf function. Regards Pavel > > 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
