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

From Itagaki Takahiro
Subject Re: patch (for 9.1) string functions
Date
Msg-id AANLkTik+w153TvJfPyhGw6QqdJzi1f1TvvyzU=_ME6S1@mail.gmail.com
Whole thread Raw
In response to Re: patch (for 9.1) string functions  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: patch (for 9.1) string functions  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
2010/7/26 Robert Haas <robertmhaas@gmail.com>:
> Come to think of it, have we checked that the behavior of LEFT, RIGHT,
> REVERSE, etc. is the same on other DBs, especially as far as nulls,
> empty strings, too-large or negative subscripts, etc is concerned?  Is
> CONCAT('foo', NULL) => 'foo' really the behavior that everyone else
> implements here?

I made a discussion page in wiki for the compatibility issue.
http://wiki.postgresql.org/wiki/String_Functions_and_Operators_Compatibility

Please fill empty cells and fix wrong descriptions. * concat() is not compatible between MySQL and Oracle/DB2. Which do
webuy? * How do other databases behave in left() and right() with negative lengths? * Are there any databases that has
similarfeatures with format() or 
sprintf() ?


> And why does CONCAT() take a variadic "ANY"
> argument?  Shouldn't that be variadic TEXT?

I think we have no other choice but to use VARIADIC "any" for variadic
functions.
We have all combinations of argument types for || operator, (text, text),
(text, any), (any, text), but we cannot use such codes for variadic functions
-- they have no limits of argument numbers. And in the case, the functions
should be STABLE because they convert arguments to text in it with typout
functions that might be STABLE.


IMHO, I'd repeat, syntax for format() is a bad choice because it cannot
concatenate multiple arguments without separator, though RAISE also uses it.
%s format in sprintf() or {n} syntax in C#'s String.Format() seems to be
a better design.

--
Itagaki Takahiro


pgsql-hackers by date:

Previous
From: Kris Jurka
Date:
Subject: Re: [JDBC] Trouble with COPY IN
Next
From: James William Pye
Date:
Subject: Re: [JDBC] Trouble with COPY IN