Re: patch (for 9.1) string functions
От | Pavel Stehule |
---|---|
Тема | Re: patch (for 9.1) string functions |
Дата | |
Msg-id | AANLkTikvPxPEfEL=U=tGNEXs_eiZJ27ih_sD7=-somi9@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: patch (for 9.1) string functions (Itagaki Takahiro <itagaki.takahiro@gmail.com>) |
Список | 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 по дате отправления: