Erik Rijkers wrote:
On Thu, July 29, 2010 22:43, Erik Rijkers wrote:
Hi Pavel,
In xfunc.sgml, I came across a function example (for use of VARIADIC in
polymorphic functions),
where the function name is concat(): (in the manual: 35.4.10. Polymorphic
SQL Functions).
Although that
I applied the attached patch to HEAD. concat(), concat_ws(), left(),
right(), and reverse() are in it, but format() and sprintf() are not.
It's my understanding that we don't have consensus about the best syntax
for the formatting function. We can forget about RAISE. C-like printf
syntax is the
2010/8/24 Itagaki Takahiro itagaki.takah...@gmail.com:
I applied the attached patch to HEAD. concat(), concat_ws(), left(),
right(), and reverse() are in it, but format() and sprintf() are not.
It's my understanding that we don't have consensus about the best syntax
for the formatting
On Tue, August 24, 2010 08:32, Itagaki Takahiro wrote:
I applied the attached patch to HEAD. concat(), concat_ws(), left(),
right(), and reverse() are in it, but format() and sprintf() are not.
+1 to add also sprintf
Erik Rijkers
--
Sent via pgsql-hackers mailing list
On Sat, Aug 7, 2010 at 8:39 PM, Pavel Stehule pavel.steh...@gmail.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
2010/8/23 Itagaki Takahiro itagaki.takah...@gmail.com:
On Sat, Aug 7, 2010 at 8:39 PM, Pavel Stehule pavel.steh...@gmail.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
Pavel Stehule pavel.steh...@gmail.com writes:
... The formating
enhancing should be shared with RAISE NOTICE command.
I remain of the opinion that RAISE's approach to formatting is
completely broken and inextensible, and that any attempt to be somehow
compatible with it is going to lead to an
2010/8/23 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
... The formating
enhancing should be shared with RAISE NOTICE command.
I remain of the opinion that RAISE's approach to formatting is
completely broken and inextensible, and that any attempt to be somehow
Hello
2010/8/7 Itagaki Takahiro itagaki.takah...@gmail.com:
2010/7/26 Robert Haas robertmh...@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,
2010/7/26 Robert Haas robertmh...@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
Hello
2010/7/29 Erik Rijkers e...@xs4all.nl:
On Thu, July 29, 2010 22:43, Erik Rijkers wrote:
Hi Pavel,
In xfunc.sgml, I came across a function example (for use of VARIADIC in
polymorphic functions),
where the function name is concat(): (in the manual: 35.4.10. Polymorphic
SQL
On Mon, Jul 26, 2010 at 8:48 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 26, 2010 at 3:49 PM, Merlin Moncure mmonc...@gmail.com wrote:
concat() is not a variadic text function. it is variadic any that
happens to do text coercion (not casting) inside the function. The
the
Hi Pavel,
In xfunc.sgml, I came across a function example (for use of VARIADIC in
polymorphic functions),
where the function name is concat(): (in the manual: 35.4.10. Polymorphic SQL
Functions).
Although that is not strictly wrong, it seems better to change that name when
concat goes into
On Thu, July 29, 2010 22:43, Erik Rijkers wrote:
Hi Pavel,
In xfunc.sgml, I came across a function example (for use of VARIADIC in
polymorphic functions),
where the function name is concat(): (in the manual: 35.4.10. Polymorphic
SQL Functions).
Although that is not strictly wrong, it
2010/7/26 Robert Haas robertmh...@gmail.com:
On Mon, Jul 26, 2010 at 10:39 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Mon, Jul 26, 2010 at 9:26 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 26, 2010 at 9:10 AM, Merlin Moncure mmonc...@gmail.com wrote:
CONCAT('foo', NULL) =
so any datatype is last possibility - is workaroud for custom functions.
Probably the most correct implementation of CONCAT have to contains a
parser changes - and then you can use a some internal concat function
with text only parameters. VARIADIC with any is just workaround that
is enouhg
On Mon, Jul 26, 2010 at 11:39 AM, Merlin Moncure mmonc...@gmail.com wrote:
I'm just very skeptical that we should give our functions argument
types that are essentially fantasy. CONCAT() doesn't concatenate
integers or intervals or boxes: it concatenates strings, and only
strings. Surely the
2010/7/26 Robert Haas robertmh...@gmail.com:
On Mon, Jul 26, 2010 at 11:39 AM, Merlin Moncure mmonc...@gmail.com wrote:
I'm just very skeptical that we should give our functions argument
types that are essentially fantasy. CONCAT() doesn't concatenate
integers or intervals or boxes: it
On Mon, Jul 26, 2010 at 3:07 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 26, 2010 at 2:09 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I understand, but with only text accepting, then CONCAT will has much
less benefit - you can't do a numeric list, for example
see
On Mon, Jul 26, 2010 at 2:09 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
I understand, but with only text accepting, then CONCAT will has much
less benefit - you can't do a numeric list, for example
see concat(c1::text, ',', c2::text, ',' ...)
with this is much simpler use a pipes '' ||
On Mon, Jul 26, 2010 at 3:49 PM, Merlin Moncure mmonc...@gmail.com wrote:
concat() is not a variadic text function. it is variadic any that
happens to do text coercion (not casting) inside the function. The
the assumption that concat is casting internally is probably wrong.
Suppose I had
2010/7/26 Robert Haas robertmh...@gmail.com:
On Mon, Jul 26, 2010 at 2:09 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I understand, but with only text accepting, then CONCAT will has much
less benefit - you can't do a numeric list, for example
see concat(c1::text, ',', c2::text, ','
On Sun, Jul 25, 2010 at 11:29 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
I think RAISE is badly designed. Using % as a placeholder has a limitation
to format strings. For example, format() cannot work as concat():
SELECT format('%%', 123, 456) = ERROR
It's hard to argue with this,
On Mon, Jul 26, 2010 at 8:02 AM, Robert Haas robertmh...@gmail.com wrote:
Regardless of where this function ends up, the concat_ws documentation
should contain some mention of the fact that ws is intended to mean
with separator,
big +1 on that -- I've been loosely following the thread and I
CONCAT('foo', NULL) = 'foo' really the behavior that everyone else
implements here? And why does CONCAT() take a variadic ANY
argument? Shouldn't that be variadic TEXT?
CONCAT with variadic text parameter will be limited with existing
default casts to text - for example, you can't to cast
On Mon, Jul 26, 2010 at 9:10 AM, Merlin Moncure mmonc...@gmail.com wrote:
CONCAT('foo', NULL) = 'foo' really the behavior that everyone else
implements here? And why does CONCAT() take a variadic ANY
argument? Shouldn't that be variadic TEXT?
What does that accomplish, besides forcing you
On Mon, Jul 26, 2010 at 9:26 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 26, 2010 at 9:10 AM, Merlin Moncure mmonc...@gmail.com wrote:
CONCAT('foo', NULL) = 'foo' really the behavior that everyone else
implements here? And why does CONCAT() take a variadic ANY
argument?
On Mon, Jul 26, 2010 at 10:39 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Mon, Jul 26, 2010 at 9:26 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 26, 2010 at 9:10 AM, Merlin Moncure mmonc...@gmail.com wrote:
CONCAT('foo', NULL) = 'foo' really the behavior that everyone else
On Mon, Jul 26, 2010 at 11:07 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 26, 2010 at 10:39 AM, Merlin Moncure mmonc...@gmail.com wrote:
It was absolutely a good decision because it prevented type inference
in ways that were ambiguous or surprising (for a canonical case see:
I merged and enhanced some part of your patch:
- contrib/stringfunc are merged in the core patch
- Old format() is replaced with sprintf(), but the function name is
still format().
- Support %q as alias for %iq.
2010/7/25 Pavel Stehule pavel.steh...@gmail.com:
fixed - it depends on
2010/7/26 Itagaki Takahiro itagaki.takah...@gmail.com:
I merged and enhanced some part of your patch:
- contrib/stringfunc are merged in the core patch
- Old format() is replaced with sprintf(), but the function name is
still format().
- Support %q as alias for %iq.
2010/7/25 Pavel
2010/7/26 Pavel Stehule pavel.steh...@gmail.com:
sprintf has some issue based on common sprintf implementation and
expecting too. For example a precision is used very dynamically - it
has a different sense for integers and for floats, so I wouldn't have
a sprintf in core.
Why do we need to
2010/7/26 Itagaki Takahiro itagaki.takah...@gmail.com:
2010/7/26 Pavel Stehule pavel.steh...@gmail.com:
sprintf has some issue based on common sprintf implementation and
expecting too. For example a precision is used very dynamically - it
has a different sense for integers and for floats, so I
I'm reviewing contrib part of the string functions patch.
I found an issue in sprintf() to print integer values. In this case,
'l' (for long type) is used on *all* platforms. For example,
SELECT sprintf('%d', 10);
internally uses
appendStringInfo('%ld', (int64) 10)
But there are some
Hello
2010/7/23 Itagaki Takahiro itagaki.takah...@gmail.com:
I'm reviewing contrib part of the string functions patch.
I found an issue in sprintf() to print integer values. In this case,
'l' (for long type) is used on *all* platforms. For example,
SELECT sprintf('%d', 10);
internally uses
2010/7/21 Pavel Stehule pavel.steh...@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
2010/7/23 Itagaki Takahiro itagaki.takah...@gmail.com:
2010/7/21 Pavel Stehule pavel.steh...@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
2010/7/21 Itagaki Takahiro itagaki.takah...@gmail.com:
I reviewed the core changes of the patch. I don't think we need
mb_string_info() at all. Instead, we can just call pg_mbxxx() functions.
I rewrote the patch to use pg_mbstrlen_with_len() and pg_mbcharcliplen().
What do you think the
I reviewed the core changes of the patch. I don't think we need
mb_string_info() at all. Instead, we can just call pg_mbxxx() functions.
I rewrote the patch to use pg_mbstrlen_with_len() and pg_mbcharcliplen().
What do you think the changes? It requires re-counting lengths of multi-byte
strings
Hello
I have a one idea nonstandard enhancing of sprintf - relatie often job
is a quoting in PostgreSQL. So sprintf should have a special formats
for quoted values. What do you think about
%lq ... literal quoted
%iq ... ident quoted
??
Regards
Pavel
2010/7/13 Pavel Stehule
2010/7/13 Pavel Stehule pavel.steh...@gmail.com:
so this is actualised patch:
* concat_sql removed
* left, right, reverse and concat are in core
* printf and concat_ws are in contrib
* format show NULL as NULL string
* removed an using of wide chars
I think function codes in the core
Hello
2010/7/12 Robert Haas robertmh...@gmail.com:
On Sun, Jul 11, 2010 at 10:30 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
2010/7/9 Pavel Stehule pavel.steh...@gmail.com:
I am sending a actualised patch
* removed concat_json
* renamed function rvsr to reverse
* functions
On Jul 11, 2010, at 10:32 PM, Itagaki Takahiro itagaki.takah...@gmail.com
wrote:
2010/7/12 Robert Haas robertmh...@gmail.com:
I'm all in favor of putting such things in core as are supported by
multiple competing products, but is that really true for all of these?
- concat() : MySQL,
Itagaki Takahiro itagaki.takah...@gmail.com wrote:
I'd like to move all proposed functions into the core, and not to
add contrib/stringfunc.
Still failed :-( I used UTF8 database with *locale=C* on 64bit
Linux.
char2wchar() doesn't seem to work on C locale. We should avoid
using the
2010/7/12 Kevin Grittner kevin.gritt...@wicourts.gov:
Itagaki Takahiro itagaki.takah...@gmail.com wrote:
I'd like to move all proposed functions into the core, and not to
add contrib/stringfunc.
Still failed :-( I used UTF8 database with *locale=C* on 64bit
Linux.
char2wchar() doesn't
Hello
so this is actualised patch:
* concat_sql removed
* left, right, reverse and concat are in core
* printf and concat_ws are in contrib
* format show NULL as NULL string
* removed an using of wide chars
todo:
NULL handling for printf function
Query:
what is corect result for
*
2010/7/9 Pavel Stehule pavel.steh...@gmail.com:
I am sending a actualised patch
* removed concat_json
* renamed function rvsr to reverse
* functions format, sprintf and concat* are stable now (as to_char for
example)
I'd like to move all proposed functions into the core, and not to add
On Sun, Jul 11, 2010 at 10:30 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
2010/7/9 Pavel Stehule pavel.steh...@gmail.com:
I am sending a actualised patch
* removed concat_json
* renamed function rvsr to reverse
* functions format, sprintf and concat* are stable now (as to_char for
2010/7/12 Robert Haas robertmh...@gmail.com:
I'm all in favor of putting such things in core as are supported by
multiple competing products, but is that really true for all of these?
- concat() : MySQL, Oracle, DB2
- concat_ws() : MySQL,
- left(), right() : MySQL, SQL Server, DB2
- reverse() :
contrib/stringfunc was missing this small change in contrib/Makefile, I think.
With it, it
installs and runs make check cleanly.
Erik Rijkers
stringfunc_fix.diff
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
hello
2010/7/9 Takahiro Itagaki itagaki.takah...@gmail.com:
2010/7/8 Pavel Stehule pavel.steh...@gmail.com:
sorry, attached fixed patch
Make installcheck for contrib/stringfunc is broken.
Please run regression test with --enable-cassert build.
test stringfunc ... TRAP:
Pavel Stehule pavel.steh...@gmail.com wrote:
updated version, concat function doesn't use separator
BTW, didn't you forget stringfunc.sql.in for contrib/stringfunc ?
So, I have not check stringfunc module yet.
I reviewed your patch, and format() in the core is almost ok. It's very cool!
On
2010/7/8 Pavel Stehule pavel.steh...@gmail.com:
sorry, attached fixed patch
Make installcheck for contrib/stringfunc is broken.
Please run regression test with --enable-cassert build.
test stringfunc ... TRAP:
FailedAssertion(!(!lc_ctype_is_c()), File: mbutils.c, Line: 715)
LOG:
On Mar 9, 2010, at 6:30 AM, Pavel Stehule wrote:
this patch contains a string formatting function format
postgres=# select format('some message: % (current user: %)',
current_date, current_user);
format
some message:
2010/3/9 David E. Wheeler da...@kineticode.com:
On Mar 9, 2010, at 6:30 AM, Pavel Stehule wrote:
this patch contains a string formatting function format
postgres=# select format('some message: % (current user: %)',
current_date, current_user);
format
Hello
this patch contains a string formatting function format
postgres=# select format('some message: % (current user: %)',
current_date, current_user);
format
some message: 2010-03-09 (current user: pavel)
(1 row)
this
Pavel Stehule wrote:
Hello
this patch contains a string formatting function format
Hi Pavel,
This is supercool. Haven't tried it out yet but surely will, thanks!
Yeb Havinga
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Tue, Mar 9, 2010 at 9:30 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
postgres=# select concat('ahaha',10,null,current_date, true);
concat
ahaha,10,,2010-03-09,t
why are there commas in the output?
merlin
--
Sent via pgsql-hackers mailing list
2010/3/9 Merlin Moncure mmonc...@gmail.com:
On Tue, Mar 9, 2010 at 9:30 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
postgres=# select concat('ahaha',10,null,current_date, true);
concat
ahaha,10,,2010-03-09,t
why are there commas in the output?
I
updated version, concat function doesn't use separator
Pavel
2010/3/9 Pavel Stehule pavel.steh...@gmail.com:
2010/3/9 Merlin Moncure mmonc...@gmail.com:
On Tue, Mar 9, 2010 at 9:30 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
postgres=# select concat('ahaha',10,null,current_date, true);
On Tue, Mar 9, 2010 at 1:45 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
updated version, concat function doesn't use separator
btw...very cool stuff. I took a brief look at the sprintf
implementation. The main switch:
switch (pdesc.field_type)
It looks like format codes we choose not to
2010/3/9 Merlin Moncure mmonc...@gmail.com:
On Tue, Mar 9, 2010 at 1:45 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
updated version, concat function doesn't use separator
btw...very cool stuff. I took a brief look at the sprintf
implementation. The main switch:
switch
62 matches
Mail list logo
