From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used |
Date: | 2012-12-29 19:28:58 |
Message-ID: | 20121229192858.GZ16126@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Pavel Stehule (pavel(dot)stehule(at)gmail(dot)com) wrote:
> ok, so what is proposed solution?
My recommendation would be to match what glibc's printf does.
> I see two possibilities - a) applying my current patch - although it
> is not fully correct, b) new patch, that do necessary check and raise
> more descriptive error message.
Right, have a new patch that does error-checking and returns a better
error on that case, update the docs to reflect that restriction, and
then (ideally as an additional and independent patch..) implement the
width capability (and, ideally, the ability to pass the width as an
argument, as glibc supports) which matches the glibc arguments.
Part of the reason that this restriction is in place, I believe, is
because glibc expects the width to come before any explicit argument
being passed and if an explicit argument is used for width then an
explicit argument has to be used for the value also, otherwise it
wouldn't be clear from the format which was the argument number and
which was the explicit width size.
I don't think it's a good idea to come up with our own format
definition, particularly one which looks so similar to the well-known
printf() format.
> I have not strong preferences in this topic - both variants are
> acceptable for me and I invite any community opinion. But current
> state is not intuitive and should be fixed.
Agreed.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2012-12-29 19:35:57 | Re: enhanced error fields |
Previous Message | Peter Geoghegan | 2012-12-29 19:24:07 | Re: enhanced error fields |