Peter Eisentraut writes:
> On tor, 2010-08-05 at 14:38 -0400, Tom Lane wrote:
>> Huh? The functionality proposed for removal is only that of omitting
>> an explicit delimiter argument for string_agg(). Since the default
>> value (an empty string) doesn't seem to be the right thing all that
>> of
On tor, 2010-08-05 at 14:38 -0400, Tom Lane wrote:
> Huh? The functionality proposed for removal is only that of omitting
> an explicit delimiter argument for string_agg(). Since the default
> value (an empty string) doesn't seem to be the right thing all that
> often anyway, I'm not following wh
Robert Haas writes:
> On Thu, Aug 5, 2010 at 3:16 PM, Tom Lane wrote:
>> Next question: exactly how should the variant HINT be phrased?
>> I'm inclined to drop the bit about explicit casts and make it read
>> something like
>>
>> HINT: No aggregate function matches the given name and argument
>>
On Aug 5, 2010, at 12:16 PM, Tom Lane wrote:
> HINT: No aggregate function matches the given name and argument
> types. Perhaps you misplaced ORDER BY; ORDER BY must appear after all
> regular arguments of the aggregate.
+1
David
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
On Thu, Aug 5, 2010 at 3:16 PM, Tom Lane wrote:
> Josh Berkus writes:
>>> Well, maybe we need to expend some more sweat on the error message then.
>>> But this patch was still a prerequisite thing, because without it there
>>> is no error that we can complain about.
>
>> Yes, I'd say an addition
Josh Berkus writes:
>> Well, maybe we need to expend some more sweat on the error message then.
>> But this patch was still a prerequisite thing, because without it there
>> is no error that we can complain about.
> Yes, I'd say an addition to the HINT is in order *assuming* at that
> stage we ca
> Well, maybe we need to expend some more sweat on the error message then.
> But this patch was still a prerequisite thing, because without it there
> is no error that we can complain about.
Yes, I'd say an addition to the HINT is in order *assuming* at that
stage we can tell if the user passed a
On Aug 5, 2010, at 11:45 AM, Tom Lane wrote:
>> I'm confused: that looks like the two-argument form to me. Have I missed
>> something?
>
> Yeah, the whole point of the thread: that's not a call of a two-argument
> aggregate. It's a call of a one-argument aggregate, using a two-column
> sort key
On Aug 5, 2010, at 11:42 AM, Thom Brown wrote:
>>> LINE 1: select string_agg(f1 order by f1, ',') from text_tbl;
>>> ^
>>
>> I'm confused: that looks like the two-argument form to me. Have I missed
>> something?
>>
>>> HINT: No function matches the given name and argument types.
"David E. Wheeler" writes:
> On Aug 5, 2010, at 11:25 AM, Tom Lane wrote:
>> Applied to HEAD and 9.0. The mistaken case will now yield this:
>> regression=# select string_agg(f1 order by f1, ',') from text_tbl;
>> ERROR: function string_agg(text) does not exist
> I'm confused: that looks like t
On Thu, Aug 5, 2010 at 12:25, Tom Lane wrote:
> regression=# select string_agg(f1 order by f1, ',') from text_tbl;
> ERROR: function string_agg(text) does not exist
> LINE 1: select string_agg(f1 order by f1, ',') from text_tbl;
> ^
> HINT: No function matches the given name and ar
On 5 August 2010 19:39, David E. Wheeler wrote:
> On Aug 5, 2010, at 11:25 AM, Tom Lane wrote:
>
>> Applied to HEAD and 9.0. The mistaken case will now yield this:
>>
>> regression=# select string_agg(f1 order by f1, ',') from text_tbl;
>> ERROR: function string_agg(text) does not exist
>> LINE
On Aug 5, 2010, at 11:25 AM, Tom Lane wrote:
> Applied to HEAD and 9.0. The mistaken case will now yield this:
>
> regression=# select string_agg(f1 order by f1, ',') from text_tbl;
> ERROR: function string_agg(text) does not exist
> LINE 1: select string_agg(f1 order by f1, ',') from text_tbl;
Peter Eisentraut writes:
> I vote against this patch. There are plenty of other places that SQL is
> confusing, and this move seems excessive to me, and I find the
> functionality that is proposed for removal quite useful.
Huh? The functionality proposed for removal is only that of omitting an
On ons, 2010-08-04 at 18:19 -0400, Tom Lane wrote:
>
> This policy also implies that we are never going to allow default
> arguments for aggregates, or at least never have any built-in ones
> that use such a feature.
>
> By my count the following people had offered an opinion on making
> this cha
I wrote:
> Well, I forgot that an aggregate involves more than one catalog row ;-).
> So it's a bit bigger patch than that, but still pretty small and safe.
> See attached.
Applied to HEAD and 9.0. The mistaken case will now yield this:
regression=# select string_agg(f1 order by f1, ',') from te
2010/8/5 Tom Lane :
> Pavel Stehule writes:
>> but still when we remove one parametric string_agg, then this issue
>> will not be documented.
>
> How so? This paragraph will still be there:
>
>
> When dealing with multiple-argument aggregate functions, note that the
> ORDER BY clause goe
On 5 August 2010 16:31, Pavel Stehule wrote:
> 2010/8/5 Tom Lane :
>> Pavel Stehule writes:
>> The same problem can be with custom aggregates :( so this syntax isn't
>> too robust.
>>
>> BTW, I'm really not worried about that case. By the time someone is
>> advanced enough to have writte
Pavel Stehule writes:
> but still when we remove one parametric string_agg, then this issue
> will not be documented.
How so? This paragraph will still be there:
When dealing with multiple-argument aggregate functions, note that the
ORDER BY clause goes after all the aggregate argum
2010/8/5 Tom Lane :
> Pavel Stehule writes:
> The same problem can be with custom aggregates :( so this syntax isn't
> too robust.
>
> BTW, I'm really not worried about that case. By the time someone is
> advanced enough to have written their own multi-argument aggregate
> definitions, th
Pavel Stehule writes:
The same problem can be with custom aggregates :( so this syntax isn't
too robust.
BTW, I'm really not worried about that case. By the time someone is
advanced enough to have written their own multi-argument aggregate
definitions, they'll have absorbed the idea th
2010/8/5 Tom Lane :
> Thom Brown writes:
>> On 5 August 2010 10:29, Greg Stark wrote:
>>> On Thu, Aug 5, 2010 at 5:18 AM, Pavel Stehule
>>> wrote:
The same problem can be with custom aggregates :( so this syntax isn't
too robust. We can support Oracle's syntax in future releases, wher
Thom Brown writes:
> On 5 August 2010 10:29, Greg Stark wrote:
>> On Thu, Aug 5, 2010 at 5:18 AM, Pavel Stehule
>> wrote:
>>> The same problem can be with custom aggregates :( so this syntax isn't
>>> too robust. We can support Oracle's syntax in future releases, where
>>> syntax divide aggrega
On 5 August 2010 10:29, Greg Stark wrote:
> On Thu, Aug 5, 2010 at 5:18 AM, Pavel Stehule wrote:
>> The same problem can be with custom aggregates :( so this syntax isn't
>> too robust. We can support Oracle's syntax in future releases, where
>> syntax divide aggregate call and ORDER BY clause.
>
On Thu, Aug 5, 2010 at 5:18 AM, Pavel Stehule wrote:
> The same problem can be with custom aggregates :( so this syntax isn't
> too robust. We can support Oracle's syntax in future releases, where
> syntax divide aggregate call and ORDER BY clause.
>
What syntax is that?
--
greg
--
Sent via p
2010/8/4 Kevin Grittner :
> Alex Hunsaker wrote:
>> On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
>>> If we were a bit earlier in the 9.0 cycle I would suggest that
>>> this confusion is a sufficient reason to drop the one-argument
>>> form of string_agg. It's too late now though.
>>
The same p
On Wed, Aug 4, 2010 at 6:19 PM, Tom Lane wrote:
> for: tgl, josh, badalex, mmoncure
> against: rhaas, thom
> Anybody else want to vote, or change their vote after seeing the patch?
If we're not regarding this as beta-forcing, I abstain.
--
Robert Haas
EnterpriseDB: http://www.ente
On Wed, Aug 4, 2010 at 17:07, Tom Lane wrote:
> Alex Hunsaker writes:
>> I dunno about anyone else but (a, ',' order by a) just looks weird.
>
> I suppose, but aren't you just focusing on the argument being constant?
Yes.
>> Or in other words, any thoughts on:
>> select string_agg(delim, expres
On Wed, Aug 4, 2010 at 7:07 PM, Tom Lane wrote:
>> Or in other words, any thoughts on:
>> select string_agg(delim, expression);
>
> That looks pretty weird to me anyway, with or without use of ORDER BY.
> Nobody would think to write the delimiter first. Usually you put the
> "most important" argu
Alex Hunsaker writes:
> I dunno about anyone else but (a, ',' order by a) just looks weird.
I suppose, but aren't you just focusing on the argument being constant?
In the more general case I don't think there's anything unnatural about
this syntax.
> Or in other words, any thoughts on:
> select
On Wed, Aug 4, 2010 at 16:33, Thom Brown wrote:
> I was afraid that the function would be pulled completely, but from
> looking at the patch, you're only removing the function with a
> single-parameter signature, which is quite innocuous. So I'm "for"
> now.
Ahh, Now I see why you were worried
On Wed, Aug 04, 2010 at 06:19:49PM -0400, Tom Lane wrote:
> I wrote:
> > Hm? I don't think that an initdb here would have any impact on whether
> > we can call the next drop RC1 or not. We're talking about removing a
> > single built-in entry in pg_proc --- it's one of the safest changes we
> > c
Thom Brown writes:
> I was afraid that the function would be pulled completely, but from
> looking at the patch, you're only removing the function with a
> single-parameter signature, which is quite innocuous.
Yes, of course, sorry if I confused anyone. It's the combination of
having both one- a
On 4 August 2010 23:19, Tom Lane wrote:
> I wrote:
>> Hm? I don't think that an initdb here would have any impact on whether
>> we can call the next drop RC1 or not. We're talking about removing a
>> single built-in entry in pg_proc --- it's one of the safest changes we
>> could possibly make.
>
I wrote:
> Hm? I don't think that an initdb here would have any impact on whether
> we can call the next drop RC1 or not. We're talking about removing a
> single built-in entry in pg_proc --- it's one of the safest changes we
> could possibly make.
Well, I forgot that an aggregate involves more
On Wed, Aug 4, 2010 at 3:11 PM, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
>>> If we were a bit earlier in the 9.0 cycle I would suggest that this
>>> confusion is a sufficient reason to drop the one-argument form of
>>> string_agg. It's too late now
On Wed, Aug 04, 2010 at 09:02:43PM +0100, Thom Brown wrote:
> On 4 August 2010 20:58, Josh Berkus wrote:
> >
> >> Great, I was afraid people would want another beta if we forced
> >> an initdb. So a hearty +1 for fixing it and not doing another
> >> beta (pending other bugs obviously).
> >
> > An
On 4 August 2010 20:58, Josh Berkus wrote:
>
>> Great, I was afraid people would want another beta if we forced an
>> initdb. So a hearty +1 for fixing it and not doing another beta
>> (pending other bugs obviously).
>
> And, btw, there has been a lot of testing of pg_upgrade due to the
> initdbs
> Great, I was afraid people would want another beta if we forced an
> initdb. So a hearty +1 for fixing it and not doing another beta
> (pending other bugs obviously).
And, btw, there has been a lot of testing of pg_upgrade due to the
initdbs and otherwise. I think 9.0 is going to have a prett
On Wed, Aug 4, 2010 at 13:42, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Aug 4, 2010 at 3:25 PM, Alex Hunsaker wrote:
>>> I think forcing an initdb might be more trouble than this wart is worth.
>
>> +1. I would not make this change unless we have to force an initdb
>> anyway. And I real
04.Ağu.2010 tarihinde 22:44 saatinde, Josh Berkus
şunları yazdı:
I'm OK with forcing an initDB for RC1.
I think beta5 will be a better choice than RC 1 here.
--
Devrim GÜNDÜZ
PostgreSQL DBA @ Akinon/Markafoni, Red Hat Certified Engineer
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gundu
Josh Berkus writes:
> If it's causing bugs, drop it now. If we include it in 9.0, we're stuck
> with it for years.
Well, it's causing bug reports, which is not exactly the same thing as bugs.
But yeah, I'm thinking we should get rid of it.
regards, tom lane
--
Sent via
> Well, it'd take an initdb to get rid of it. In the past we've avoided
> forcing initdb post-beta1 unless it was Really Necessary. OTOH, we seem
> to be in the mode of encouraging beta testers to test pg_upgrade, so
> maybe that concern isn't worth much at the moment.
If it's causing bugs, dro
Robert Haas writes:
> On Wed, Aug 4, 2010 at 3:25 PM, Alex Hunsaker wrote:
>> I think forcing an initdb might be more trouble than this wart is worth.
> +1. I would not make this change unless we have to force an initdb
> anyway. And I really hope we don't, because I'm sort of hoping the
> nex
On 4 August 2010 20:25, Alex Hunsaker wrote:
> On Wed, Aug 4, 2010 at 13:11, Tom Lane wrote:
>> Alex Hunsaker writes:
>>> On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
If we were a bit earlier in the 9.0 cycle I would suggest that this
confusion is a sufficient reason to drop the one-
Alex Hunsaker writes:
> Either way, I don't have strong feelings on this other than if we dont
> fix it now when will we?
Well, we won't. If 9.0 ships with both forms of string_agg, we're stuck
with it IMO. It's not exactly a bug, so I won't cry if that's how
things go; but it is striking that
On Wed, Aug 4, 2010 at 3:25 PM, Alex Hunsaker wrote:
> I think forcing an initdb might be more trouble than this wart is worth.
+1. I would not make this change unless we have to force an initdb
anyway. And I really hope we don't, because I'm sort of hoping the
next 9.0 release will be rc1.
--
On Wed, Aug 4, 2010 at 13:11, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
>>> If we were a bit earlier in the 9.0 cycle I would suggest that this
>>> confusion is a sufficient reason to drop the one-argument form of
>>> string_agg. It's too late now t
Alex Hunsaker writes:
> On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
>> If we were a bit earlier in the 9.0 cycle I would suggest that this
>> confusion is a sufficient reason to drop the one-argument form of
>> string_agg. It's too late now though.
> FWIW I think we can still change it. Isn'
Alex Hunsaker wrote:
> On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
>> If we were a bit earlier in the 9.0 cycle I would suggest that
>> this confusion is a sufficient reason to drop the one-argument
>> form of string_agg. It's too late now though.
>
> FWIW I think we can still change it. Is
On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
> If we were a bit earlier in the 9.0 cycle I would suggest that this
> confusion is a sufficient reason to drop the one-argument form of
> string_agg. It's too late now though.
FWIW I think we can still change it. Isn't this type of issue part
of
On Wed, Aug 4, 2010 at 1:04 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Aug 4, 2010 at 12:44 PM, Tom Lane wrote:
>>> Robert Haas writes:
I suppose this confusion is only possible because string_agg has both
a one-argument and a two-argument form.
>>>
>>> Right, or at least th
Robert Haas writes:
> On Wed, Aug 4, 2010 at 12:44 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> I suppose this confusion is only possible because string_agg has both
>>> a one-argument and a two-argument form.
>>
>> Right, or at least that's what allows the mistake to go through without
>> re
On Wed, Aug 4, 2010 at 12:44 PM, Tom Lane wrote:
> Robert Haas writes:
>> I suppose this confusion is only possible because string_agg has both
>> a one-argument and a two-argument form.
>
> Right, or at least that's what allows the mistake to go through without
> reporting any error.
No, that'
Robert Haas writes:
> I suppose this confusion is only possible because string_agg has both
> a one-argument and a two-argument form.
Right, or at least that's what allows the mistake to go through without
reporting any error.
regards, tom lane
--
Sent via pgsql-bugs m
On Wed, Aug 4, 2010 at 11:29 AM, Tom Lane wrote:
> Robert Haas writes:
>> Oh, yeah. I guess you need this:
>
>> select thing, string_agg(stuff, ',' order by stuff) from agg_test
>> group by thing;
>
>> Rather than this:
>
>> select thing, string_agg(stuff order by stuff, ',') from agg_test
>> gr
Robert Haas writes:
> Oh, yeah. I guess you need this:
> select thing, string_agg(stuff, ',' order by stuff) from agg_test
> group by thing;
> Rather than this:
> select thing, string_agg(stuff order by stuff, ',') from agg_test
> group by thing;
> It's all kinds of not obvious to me what the
2010/8/4 Thom Brown :
> On 4 August 2010 14:24, Pavel Stehule wrote:
>> 2010/8/4 Thom Brown :
>>> On 4 August 2010 14:04, Robert Haas wrote:
On Wed, Aug 4, 2010 at 6:03 AM, Thom Brown wrote:
> Actually, this rings a bell. I think this may have been raised
> before, something to do
On 4 August 2010 14:24, Pavel Stehule wrote:
> 2010/8/4 Thom Brown :
>> On 4 August 2010 14:04, Robert Haas wrote:
>>> On Wed, Aug 4, 2010 at 6:03 AM, Thom Brown wrote:
Actually, this rings a bell. I think this may have been raised
before, something to do with the delimiter being acce
2010/8/4 Thom Brown :
> On 4 August 2010 14:04, Robert Haas wrote:
>> On Wed, Aug 4, 2010 at 6:03 AM, Thom Brown wrote:
>>> Actually, this rings a bell. I think this may have been raised
>>> before, something to do with the delimiter being accepted as one of
>>> the order by values. If this isn
On 4 August 2010 14:04, Robert Haas wrote:
> On Wed, Aug 4, 2010 at 6:03 AM, Thom Brown wrote:
>> Actually, this rings a bell. I think this may have been raised
>> before, something to do with the delimiter being accepted as one of
>> the order by values. If this isn't really a bug, could someo
On Wed, Aug 4, 2010 at 6:03 AM, Thom Brown wrote:
> Actually, this rings a bell. I think this may have been raised
> before, something to do with the delimiter being accepted as one of
> the order by values. If this isn't really a bug, could someone
> mention it in the docs somewhere?
Oh, yeah.
On 4 August 2010 10:44, Thom Brown wrote:
> On 4 August 2010 10:36, Thom Brown wrote:
>> I'd like to report a potential bug (or just my misunderstanding), but
>> I couldn't find any mention in the TODO or on the mailing list.
>>
>> I'm using PostgreSQL 9.0 beta 3 on Gentoo x64 (sorry, I don't hav
On 4 August 2010 10:36, Thom Brown wrote:
> I'd like to report a potential bug (or just my misunderstanding), but
> I couldn't find any mention in the TODO or on the mailing list.
>
> I'm using PostgreSQL 9.0 beta 3 on Gentoo x64 (sorry, I don't have
> beta 4 yet). I attempted to use string_agg t
I'd like to report a potential bug (or just my misunderstanding), but
I couldn't find any mention in the TODO or on the mailing list.
I'm using PostgreSQL 9.0 beta 3 on Gentoo x64 (sorry, I don't have
beta 4 yet). I attempted to use string_agg to get values into a
comma-separated list as follows.
65 matches
Mail list logo
