I noticed that the regression test results don't include the following case:
select string_agg(a) from (values(null),(null)) g(a);
There is one similar where a delimiter is provided.
Which leads me to ask for clarification, would it be safe to assume that
string_agg can never itself return
2010/2/1 Thom Brown thombr...@gmail.com:
I noticed that the regression test results don't include the following case:
select string_agg(a) from (values(null),(null)) g(a);
There is one similar where a delimiter is provided.
Which leads me to ask for clarification, would it be safe to assume
On 1 February 2010 13:40, Pavel Stehule pavel.steh...@gmail.com wrote:
2010/2/1 Thom Brown thombr...@gmail.com:
I noticed that the regression test results don't include the following
case:
select string_agg(a) from (values(null),(null)) g(a);
There is one similar where a delimiter is
On Sun, Jan 31, 2010 at 10:29 PM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Applied with some editorialization. Please check the docs are good enough.
Looks pretty good. I have committed a couple very minor adjustments.
...Robert
--
Sent via pgsql-hackers mailing list
Robert Haas robertmh...@gmail.com wrote:
ok - I am only one who like original behave - so I ?am withdrawing.
Robert, If you like, please commit Itagaki's patch. + add note about
behave when second parameter isn't stable.
I haven't even looked at this code - I sort of assumed Itagaki was
2010/2/1 Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp:
Robert Haas robertmh...@gmail.com wrote:
ok - I am only one who like original behave - so I ?am withdrawing.
Robert, If you like, please commit Itagaki's patch. + add note about
behave when second parameter isn't stable.
I
On Fri, Jan 29, 2010 at 2:43 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2010/1/28 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
with get_fn_expr_arg_stable() we are able to fix second parameter
without some performance issues.
No, that will create its own
On Jan 29, 2010, at 10:43 AM, Robert Haas wrote:
I haven't even looked at this code - I sort of assumed Itagaki was
handling this one. But it might be good to make sure that the docs
have been read through by a native English speaker prior to commit...
I did and revised them slightly. There
On Fri, Jan 29, 2010 at 1:45 PM, David E. Wheeler da...@kineticode.com wrote:
On Jan 29, 2010, at 10:43 AM, Robert Haas wrote:
I haven't even looked at this code - I sort of assumed Itagaki was
handling this one. But it might be good to make sure that the docs
have been read through by a
On Jan 29, 2010, at 10:46 AM, Robert Haas wrote:
I did and revised them slightly. There isn't much, just a brief comment in
the table of aggregate functions. The documentation for all the functions on
that page could use a little love, frankly.
Want to take a short at it?
ENOTUITS! /me
2010/1/28 Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp:
Pavel Stehule pavel.steh...@gmail.com wrote:
with actualised oids
I'm checking the patch for commit, and have a couple of comments.
* I think we cannot cache the delimiter at the first call.
For example,
SELECT
2010/1/28 David E. Wheeler da...@kineticode.com:
On Jan 27, 2010, at 6:47 PM, Takahiro Itagaki wrote:
* I think we cannot cache the delimiter at the first call.
For example,
SELECT string_agg(elem, delim)
FROM (VALUES('A', ','), ('B', '+'), ('C', '*')) t(elem, delim);
should
2010/1/28 Pavel Stehule pavel.steh...@gmail.com:
2010/1/28 David E. Wheeler da...@kineticode.com:
On Jan 27, 2010, at 6:47 PM, Takahiro Itagaki wrote:
* I think we cannot cache the delimiter at the first call.
For example,
SELECT string_agg(elem, delim)
FROM (VALUES('A', ','),
Pavel Stehule pavel.steh...@gmail.com wrote:
2010/1/28 Pavel Stehule pavel.steh...@gmail.com:
2010/1/28 David E. Wheeler da...@kineticode.com:
On Jan 27, 2010, at 6:47 PM, Takahiro Itagaki wrote:
* I think we cannot cache the delimiter at the first call.
For example,
SELECT
On Thu, Jan 28, 2010 at 3:59 AM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Pavel Stehule pavel.steh...@gmail.com wrote:
2010/1/28 Pavel Stehule pavel.steh...@gmail.com:
2010/1/28 David E. Wheeler da...@kineticode.com:
On Jan 27, 2010, at 6:47 PM, Takahiro Itagaki wrote:
* I
2010/1/28 Robert Haas robertmh...@gmail.com:
On Thu, Jan 28, 2010 at 3:59 AM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Pavel Stehule pavel.steh...@gmail.com wrote:
2010/1/28 Pavel Stehule pavel.steh...@gmail.com:
2010/1/28 David E. Wheeler da...@kineticode.com:
On Jan 27,
On Thu, Jan 28, 2010 at 9:01 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
simplest could not be a best. There have to be only a const
expression. But we have not possibility to check it in pg.
Well... that's an entirely arbitrary limitation. I admit that it
doesn't seem likely that someone
2010/1/28 Robert Haas robertmh...@gmail.com:
On Thu, Jan 28, 2010 at 9:01 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
simplest could not be a best. There have to be only a const
expression. But we have not possibility to check it in pg.
Well... that's an entirely arbitrary limitation.
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 28, 2010 at 9:01 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
simplest could not be a best. There have to be only a const
expression. But we have not possibility to check it in pg.
Well... that's an entirely arbitrary limitation. I
On Thu, Jan 28, 2010 at 10:56 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 28, 2010 at 9:01 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
simplest could not be a best. There have to be only a const
expression. But we have not possibility to
On Wed, Jan 27, 2010 at 9:47 PM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
* Do we need better names for string_agg1_transfn and string_agg2_transfn?
They are almost internal names, but we could have more
like string_agg_with_sep_transfn.
Surely the names of the transition and
2010/1/29 Pavel Stehule pavel.steh...@gmail.com:
2010/1/28 Robert Haas robertmh...@gmail.com:
On Thu, Jan 28, 2010 at 9:01 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
simplest could not be a best. There have to be only a const
expression. But we have not possibility to check it in pg.
2010/1/28 Robert Haas robertmh...@gmail.com:
On Thu, Jan 28, 2010 at 10:56 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 28, 2010 at 9:01 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
simplest could not be a best. There have to be only a
2010/1/28 Robert Haas robertmh...@gmail.com:
On Wed, Jan 27, 2010 at 9:47 PM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
* Do we need better names for string_agg1_transfn and string_agg2_transfn?
They are almost internal names, but we could have more
like
Pavel Stehule pavel.steh...@gmail.com writes:
in 99.99% the second argument will be a constant. Can we use this
information and optimize function for this case?
The detoast on every row can take some percent from a performance.
What detoast? There won't be one for a constant, nor even for a
2010/1/28 Hitoshi Harada umi.tan...@gmail.com:
2010/1/29 Pavel Stehule pavel.steh...@gmail.com:
2010/1/28 Robert Haas robertmh...@gmail.com:
On Thu, Jan 28, 2010 at 9:01 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
simplest could not be a best. There have to be only a const
expression.
2010/1/28 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
in 99.99% the second argument will be a constant. Can we use this
information and optimize function for this case?
The detoast on every row can take some percent from a performance.
What detoast? There
Hitoshi Harada umi.tan...@gmail.com writes:
What about get_fn_expr_arg_stable() to check if the argument is stable
during aggregate?
Seems quite expensive (possible catalog lookups) and there still isn't
any strong argument why we should bother.
regards, tom lane
--
Pavel Stehule pavel.steh...@gmail.com writes:
with get_fn_expr_arg_stable() we are able to fix second parameter
without some performance issues.
No, that will create its own performance issues ---
get_fn_expr_arg_stable isn't especially cheap.
If there were a really strong reason why we had to
On 2010-01-28 19:17, Pavel Stehule wrote:
2010/1/28 Hitoshi Harada umi.tan...@gmail.com:
What about get_fn_expr_arg_stable() to check if the argument is stable
during aggregate?
I newer know so this function exists. Now we can
a) check and allow only stable params
b) when second
On Jan 28, 2010, at 9:29 AM, Marko Tiikkaja wrote:
Someone might have a perfectly good use case for using different
delimiters. I don't think it's a good idea to be artificially limiting
what you can and can't do.
+1
David
--
Sent via pgsql-hackers mailing list
One situation where this could actually matter in the long term is if we
want to have an optimization for aggregate functions whose state variables
can be combined. this could be important if we ever want to do parallel
processing someday.
So we could have, for example two subjobs build two
2010/1/28 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
with get_fn_expr_arg_stable() we are able to fix second parameter
without some performance issues.
No, that will create its own performance issues ---
get_fn_expr_arg_stable isn't especially cheap.
If there
with actualised oids
Regards
Pavel Stehule
2010/1/26 David E. Wheeler da...@kineticode.com:
On Jan 25, 2010, at 6:56 AM, Pavel Stehule wrote:
actualised patch - the name is string_agg
All looks fine except I'm getting this error during initdb:
creating template1 database in
On Tue, Jan 26, 2010 at 1:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 26, 2010 at 12:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
But what it *produces* is a string. For comparison, the
SQL-standard-specified array_agg produces arrays, but what
On Jan 27, 2010, at 7:58 AM, Pavel Stehule wrote:
with actualised oids
Thanks. Looks good, modulo my preference for concat_agg(). I'll mark it ready
for committer.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Pavel Stehule pavel.steh...@gmail.com wrote:
with actualised oids
I'm checking the patch for commit, and have a couple of comments.
* I think we cannot cache the delimiter at the first call.
For example,
SELECT string_agg(elem, delim)
FROM (VALUES('A', ','), ('B', '+'), ('C',
On Jan 27, 2010, at 6:47 PM, Takahiro Itagaki wrote:
* I think we cannot cache the delimiter at the first call.
For example,
SELECT string_agg(elem, delim)
FROM (VALUES('A', ','), ('B', '+'), ('C', '*')) t(elem, delim);
should return 'A+B*C' rather than 'A,B,C'.
Ooh, nice.
* Can
On Jan 25, 2010, at 23:14, Pavel Stehule pavel.steh...@gmail.com
wrote:
why is concat_agg better than listagg ?
Because it's an aggregate that cocatenates values. It's not an
aggregate that lists things. I also like concat_agg better than
string_agg because it's not limited to acting on
On Tue, Jan 26, 2010 at 1:08 PM, David E. Wheeler da...@kineticode.com wrote:
.
Because it's an aggregate that cocatenates values. It's not an aggregate
that lists things. I also like concat_agg better than string_agg because
it's not limited to acting on strings.
.
Given that it
On Tue, Jan 26, 2010 at 1:23 PM, Alastair Turner b...@ctrlf5.co.za wrote:
.
Given that it potentially produces a delimited list, not a straight
conacatenation (and that list is unacceptable since it would be
descriptive as a noun but not as a verb) would implode_agg not be the
most
On tis, 2010-01-26 at 03:08 -0800, David E. Wheeler wrote:
On Jan 25, 2010, at 23:14, Pavel Stehule pavel.steh...@gmail.com
wrote:
why is concat_agg better than listagg ?
Because it's an aggregate that cocatenates values. It's not an
aggregate that lists things. I also like
On Tue, Jan 26, 2010 at 2:14 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2010/1/25 Robert Haas robertmh...@gmail.com:
On Mon, Jan 25, 2010 at 2:27 PM, David E. Wheeler da...@kineticode.com
wrote:
On Jan 25, 2010, at 2:09 AM, Peter Eisentraut wrote:
xmlagg - concatenates values to form
2010/1/26 Robert Haas robertmh...@gmail.com:
On Tue, Jan 26, 2010 at 2:14 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2010/1/25 Robert Haas robertmh...@gmail.com:
On Mon, Jan 25, 2010 at 2:27 PM, David E. Wheeler da...@kineticode.com
wrote:
On Jan 25, 2010, at 2:09 AM, Peter
On Jan 26, 2010, at 4:03, Peter Eisentraut pete...@gmx.net wrote:
What else can it act on?
Any data type, since they all can be converted to text. Integers would
be a common choice.
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Pavel Stehule pavel.steh...@gmail.com writes:
2010/1/25 Robert Haas robertmh...@gmail.com:
On Mon, Jan 25, 2010 at 2:27 PM, David E. Wheeler da...@kineticode.com
wrote:
concat_agg().
I like that one...
why is concat_agg better than listagg ?
It isn't ... it's the wrong part of speech.
Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
why is concat_agg better than listagg ?
It isn't ... it's the wrong part of speech. concatenate is a
verb,
Concatenation is a noun. concat doesn't get far enough to
distinguish.
-Kevin
--
Sent via
David E. Wheeler da...@kineticode.com writes:
Because it's an aggregate that cocatenates values. It's not an
aggregate that lists things. I also like concat_agg better than
string_agg because it's not limited to acting on strings.
But what it *produces* is a string. For comparison, the
On Jan 26, 2010, at 9:36 AM, Tom Lane wrote:
But what it *produces* is a string. For comparison, the
SQL-standard-specified array_agg produces arrays, but what it
acts on isn't an array.
Meh. This is all just bike-shedding. I'm fine with string_agg(), though in
truth none of the names has
David E. Wheeler da...@kineticode.com writes:
Meh. This is all just bike-shedding. I'm fine with string_agg(), though in
truth none of the names has really been great. The inclusion of agg in the
name is unfortunate.
Yeah, I wouldn't be for it either if it weren't for the precedent of
On Jan 25, 2010, at 6:56 AM, Pavel Stehule wrote:
actualised patch - the name is string_agg
All looks fine except I'm getting this error during initdb:
creating template1 database in /usr/local/pgsql-devel/data/base/1 ... FATAL:
could not create unique index pg_proc_oid_index
DETAIL: Key
On Tue, Jan 26, 2010 at 12:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
Because it's an aggregate that cocatenates values. It's not an
aggregate that lists things. I also like concat_agg better than
string_agg because it's not limited to acting on
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 26, 2010 at 12:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
But what it *produces* is a string. For comparison, the
SQL-standard-specified array_agg produces arrays, but what it
acts on isn't an array.
This point is well-taken, but naming
On sön, 2010-01-24 at 21:29 -0800, Scott Bailey wrote:
I think listagg or string_agg would be the most appropriate names. Oh
and before Oracle had wm_concat, Tom Kyte wrote a function called
stragg that was pretty popular.
Well,
xmlagg - concatenates values to form xml datum
array_agg -
2010/1/25 Peter Eisentraut pete...@gmx.net:
On sön, 2010-01-24 at 21:29 -0800, Scott Bailey wrote:
I think listagg or string_agg would be the most appropriate names. Oh
and before Oracle had wm_concat, Tom Kyte wrote a function called
stragg that was pretty popular.
Well,
xmlagg -
Pavel Stehule pavel.steh...@gmail.com writes:
2010/1/25 Peter Eisentraut pete...@gmx.net:
xmlagg - concatenates values to form xml datum
array_agg - concatenates values to form array datum
??? - concatenates values to form string datum
So it's pretty clear that listagg does not fit into
2010/1/25 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2010/1/25 Peter Eisentraut pete...@gmx.net:
xmlagg - concatenates values to form xml datum
array_agg - concatenates values to form array datum
??? - concatenates values to form string datum
So it's pretty
2010/1/25 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2010/1/25 Peter Eisentraut pete...@gmx.net:
xmlagg - concatenates values to form xml datum
array_agg - concatenates values to form array datum
??? - concatenates values to form string datum
So it's pretty
2010/1/24 Tom Lane t...@sss.pgh.pa.us:
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2010-01-22 at 11:14 -0800, David E.Wheeler wrote:
No performance issues
ISTM that this class of function is inherently dangerous performance
wise.
* It looks incredibly easy to construct enormous
On Jan 25, 2010, at 2:09 AM, Peter Eisentraut wrote:
xmlagg - concatenates values to form xml datum
array_agg - concatenates values to form array datum
??? - concatenates values to form string datum
concat_agg().
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On Jan 25, 2010, at 6:12 AM, Pavel Stehule wrote:
I am not happy, I thing so we do bigger chaos then it is. But it
hasn't progress. So I agree with name string_agg. In this case isn't a
problem rename this function if somebody would.
Could you not use CREATE AGGREGATE to create an alias named
On Mon, Jan 25, 2010 at 2:27 PM, David E. Wheeler da...@kineticode.com wrote:
On Jan 25, 2010, at 2:09 AM, Peter Eisentraut wrote:
xmlagg - concatenates values to form xml datum
array_agg - concatenates values to form array datum
??? - concatenates values to form string datum
concat_agg().
2010/1/25 David E. Wheeler da...@kineticode.com:
On Jan 25, 2010, at 6:12 AM, Pavel Stehule wrote:
I am not happy, I thing so we do bigger chaos then it is. But it
hasn't progress. So I agree with name string_agg. In this case isn't a
problem rename this function if somebody would.
Could
2010/1/25 Robert Haas robertmh...@gmail.com:
On Mon, Jan 25, 2010 at 2:27 PM, David E. Wheeler da...@kineticode.com
wrote:
On Jan 25, 2010, at 2:09 AM, Peter Eisentraut wrote:
xmlagg - concatenates values to form xml datum
array_agg - concatenates values to form array datum
??? -
Hello
2010/1/22 David E. Wheeler da...@kineticode.com:
Pavel,
My review of your listagg patch.
Submission Review
-
* The diff is a context diff and applies cleanly to HEAD (with just two hunks
offset by 2 lines each).
* There is documentation, though I'm not sure it
On Jan 24, 2010, at 1:19 AM, Pavel Stehule wrote:
can I help with it, please. My English is terrible.
Yes, I added a bit in the patch I submitted.
array user functions are used more time in pg core. The complexity of
array functions are much higher, so I don't think we need special
file.
On Fri, 2010-01-22 at 11:14 -0800, David E.Wheeler wrote:
No performance issues
ISTM that this class of function is inherently dangerous performance
wise.
* It looks incredibly easy to construct enormous lists. We should test
the explosion limit of this to see how it is handled. Perhaps we
2010/1/24 Simon Riggs si...@2ndquadrant.com:
On Fri, 2010-01-22 at 11:14 -0800, David E.Wheeler wrote:
No performance issues
ISTM that this class of function is inherently dangerous performance
wise.
there is potencial risk, but this risk isn't new. The almost all what
you say is true for
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2010-01-22 at 11:14 -0800, David E.Wheeler wrote:
No performance issues
ISTM that this class of function is inherently dangerous performance
wise.
* It looks incredibly easy to construct enormous lists. We should test
the explosion limit
2010/1/24 David E. Wheeler da...@kineticode.com:
On Jan 24, 2010, at 1:19 AM, Pavel Stehule wrote:
can I help with it, please. My English is terrible.
Yes, I added a bit in the patch I submitted.
array user functions are used more time in pg core. The complexity of
array functions are much
I don't think. When we have function, with same parameters, same
behave like some Oracle function, then I am strongly prefer Oracle
name. I don't see any benefit from different name. It can only confuse
developers and add the trable to people who porting applications.
Meh. If the name is
71 matches
Mail list logo
