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

From Stephen Frost
Subject Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used
Date
Msg-id 20121229192858.GZ16126@tamriel.snowman.net
Whole thread Raw
In response to Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
* Pavel Stehule (pavel.stehule@gmail.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

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: enhanced error fields
Next
From: Pavel Stehule
Date:
Subject: Re: enhanced error fields