Re: patch (for 9.1) string functions - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: patch (for 9.1) string functions
Date
Msg-id AANLkTikvPxPEfEL=U=tGNEXs_eiZJ27ih_sD7=-somi9@mail.gmail.com
Whole thread Raw
In response to Re: patch (for 9.1) string functions  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
List pgsql-hackers
2010/7/23 Itagaki Takahiro <itagaki.takahiro@gmail.com>:
> 2010/7/21 Pavel Stehule <pavel.stehule@gmail.com>:
>> It is about 2% slower for UTF8 encoding. So it isn't significant for me.
>> I agree with your changes. Thank You very much
>
> Thanks. The core-part is almost ready to commit.
> I'll continue to review the contrib part.
>
> But I found there is a design issue in format() :
> Appending a '%' is common use-case, but format() cannot append
> % char without any spaces between placeholder and the raw % char.
>
> itagaki=# SELECT format('%%%', 10), format('% %%', 10);
>  format | format
> --------+--------
>  %10    | 10 %
> (1 row)
>
> It is a design issue, and RAISE in PL/pgSQL has the same issue, too.
> Do we accept the restriction? Or should we add another escape
> syntax and/or placeholder pattern?
>

I prefer a current behave - RAISE statement uses same and it is not
reported as bug for ten years, what I read a mailing lists. I would to
have a FORMAT implementation simple as possible.

and there is simple workaround:

postgres=# create or replace function fx()
returns void as $$
begin raise notice '>>>%<<<', '%';
end;
$$ language plpgsql;
CREATE FUNCTION
Time: 560.063 ms
postgres=# select fx();
NOTICE:  >>>%<<<fx
────

(1 row)

Regards

Pavel Stehule

> --
> Itagaki Takahiro
>


pgsql-hackers by date:

Previous
From: KaiGai Kohei
Date:
Subject: Re: security label support, part.2
Next
From: Itagaki Takahiro
Date:
Subject: Re: patch (for 9.1) string functions