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
Josh Berkus writes:
> On 8/5/10 12:18 PM, Robert Haas wrote:
>> Could we arrange to emit this error message only when there is an
>> aggregate with the same name but different arguments?
> Personally, I don't see this as really necessary. Just mentioning ORDER
> BY in the hint will be enough to
On 8/5/10 12:18 PM, Robert Haas wrote:
> Could we arrange to emit this error message only when there is an
> aggregate with the same name but different arguments?
Personally, I don't see this as really necessary. Just mentioning ORDER
BY in the hint will be enough to give people the right place t
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-hackers mailing list (pgsql-hackers@postgres
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
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
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
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
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'
33 matches
Mail list logo
