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

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used
Дата
Msg-id 20121229192858.GZ16126@tamriel.snowman.net
обсуждение исходный текст
Ответ на 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>)
Ответы Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used
Список 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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: enhanced error fields
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: enhanced error fields