Re: string function - "format" function proposal

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: string function - "format" function proposal
Дата
Msg-id AANLkTik4kdGfzg3btgzXvz_xD7ecHjHEBdYuLm4DQYpi@mail.gmail.com
обсуждение исходный текст
Ответ на string function - "format" function proposal  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: string function - "format" function proposal  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
On Wed, Oct 13, 2010 at 10:03 PM, Itagaki Takahiro
<itagaki.takahiro@gmail.com> wrote:
> On Thu, Oct 14, 2010 at 10:23 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Wed, Sep 29, 2010 at 3:59 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>>> [ updated patch, in response to a review from Itagaki Takahiro ]
>>
>> This patch appears to be waiting for a second round of review.
>> Itagaki-san, are you planning to do that?
>
> I can, but I was waiting for other people's comments about the design:
>  - format() in core, that implements %s, %i, and %l.
>  - substitute() for $n format and sprintf() that partially implements
>    the same function in C in contrib/stringfunc.
>
> I don't like having three similar functions for the same purpose,
> but Pavel said they are the best solutions. What will be our consensus?

<rereads thread>

I agree with you.  I think we should pick one implementation and just
go with it.  There's nothing to say that Pavel can't distribute his
own code however he likes, but I don't think there's any compelling
reason for us to carry all that code in the main tree, even in
/contrib.  Let's make format support %s, %i, and %l, as well as
allowing things like %$3l (meaning, escape the third argument as a
literal and interpolate here), and call it good.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Itagaki Takahiro
Дата:
Сообщение: Re: string function - "format" function proposal
Следующее
От: Andrew Geery
Дата:
Сообщение: Re: Re: starting to review the Extend NOT NULL representation to pg_constraint patch