Re: patch (for 9.1) string functions

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Erik Rijkers <er(at)xs4all(dot)nl>
Subject: Re: patch (for 9.1) string functions
Date: 2010-08-23 11:29:53
Message-ID: AANLkTimxW--56RdtE4pPZ_UuPrhZw1UdErXVTUfCMK8f@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2010/8/23 Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>:
> On Sat, Aug 7, 2010 at 8:39 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>>> I made a discussion page in wiki for the compatibility issue.
>>> http://wiki.postgresql.org/wiki/String_Functions_and_Operators_Compatibility
>> nice, thank you
>
> I filled cells for SQL Server and DB2.
>
>>>  * concat() is not compatible between MySQL and Oracle/DB2. Which do we buy?
>> I prefer a our implementation - it skip a NULL values and it has a
>> variadic arguments.
>
> OK. I'm going to put both concat() and concat_ws() into core.
>
>>>  * How do other databases behave in left() and right() with negative lengths?
>> little bit by python substring operations.
>
> I'll respect your proposal. The behaviors for negative lengths will
> be our specific feature, but I don't see any problems there.
> Since other databases raises errors, user should have negative-protections
> in their existing codes.
>
>> I don't agree. This function isn't designed to replace string
>> concation. It is designed to build a SQL string (for dynamic SQL) or
>> format messages. It isn't designed to replace to_char function. It is
>> designed to work mainly inside PLpgSQL functions and then is
>> consistent with RAISE statement.
>
> OK. I'll revert my changes to your original format().
>
> But please wait a moment to include sprintf() and contrib/stringfunc.
> I think the function is useful, but don't want to have two versions
> of formatting functions. So, the extended features will be merged
> into format() with additional syntax something like {10s}. Then,
> we could simplify the code because some of complex format syntax
> are not so useful in SQL, especially length+string formatter (*s).

It's reason, why I moved sprintf to contrib. When you build a SQL
statement or error message, you don't need (usually) complex
formating. And when you need it, then you can use a contrib sprintf
function. I am not against to additional simply formating - but I
afraid so we will create a second "printf" function. The formating
enhancing should be shared with RAISE NOTICE command. Probably we can
share code better now, when a PLpgSQL is in core.

Regards

Pavel

>
> --
> Itagaki Takahiro
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-08-23 14:03:54 Re: [BUGS] BUG #5305: Postgres service stops when closing Windows session
Previous Message Itagaki Takahiro 2010-08-23 11:11:39 Re: patch (for 9.1) string functions