On 2015-07-17 19:57:22 +0100, Andrew Gierth wrote:
> Attached is the current version of my fix (with Jeevan's regression
> tests plus one of mine).
Pushed, thanks for the report and fix!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 2015-07-17 11:37:26 +0530, Jeevan Chalke wrote:
> However I wonder why we are supporting GROUPING SETS inside GROUPING SETS.
> On Oracle, it is throwing an error.
> We are not trying to be Oracle compatible, but just curious to know.
The SQL specification seems to be pretty unambigous about sup
Hello,
At Mon, 20 Jul 2015 15:45:21 +0530, Jeevan Chalke
wrote in
> On Sat, Jul 18, 2015 at 12:27 AM, Andrew Gierth > wrote:
>
> > > "Kyotaro" == Kyotaro HORIGUCHI
> > writes:
> >
> > Kyotaro> Hello, this looks to be a kind of thinko. The attached patch
> > Kyotaro> fixes it.
> >
> >
On Sat, Jul 18, 2015 at 12:27 AM, Andrew Gierth wrote:
> > "Kyotaro" == Kyotaro HORIGUCHI
> writes:
>
> Kyotaro> Hello, this looks to be a kind of thinko. The attached patch
> Kyotaro> fixes it.
>
> No, that's still wrong. Just knowing that there is a List is not enough
> to tell whether t
> "Kyotaro" == Kyotaro HORIGUCHI writes:
Kyotaro> Hello, this looks to be a kind of thinko. The attached patch
Kyotaro> fixes it.
No, that's still wrong. Just knowing that there is a List is not enough
to tell whether to concat it or append it.
Jeevan's original patch tries to get around
Hello, this looks to be a kind of thinko. The attached patch
fixes it.
===
According to the comment of transformGroupingSet, it assumes that
the given GROUPING SETS node is already flatted out and
flatten_grouping_sets() does that. The details of the
transformation is described in the comment for
On Wed, Jul 15, 2015 at 10:21 PM, Andrew Gierth wrote:
> > "Jeevan" == Jeevan Chalke writes:
>
> Jeevan> Hi,
> Jeevan> It looks like we do support nested GROUPING SETS, I mean Sets
> Jeevan> withing Sets, not other types. However this nesting is broken.
>
> Good catch, but I'm not yet su
> "Jeevan" == Jeevan Chalke writes:
Jeevan> Hi,
Jeevan> It looks like we do support nested GROUPING SETS, I mean Sets
Jeevan> withing Sets, not other types. However this nesting is broken.
Good catch, but I'm not yet sure your fix is correct; I'll need to look
into that.
--
Andrew (irc
David Fetter writes:
> Also is there a really great reason that bitwise operations don't work
> on NUMERIC? Lack of tuits is a good reason, but not, it seems to me,
> a great one.
Not sure that bitwise operations make too much sense on values that
are (a) possibly fractional and (b) inherently d
On Thu, May 21, 2015 at 12:24:03PM -0400, Robert Haas wrote:
> On Thu, May 21, 2015 at 12:21 PM, Andrew Gierth
> wrote:
> >> "David" == David Fetter writes:
> >
> > David> How about a more sensible data structure as a PG-specific addon.
> > David> GROUPING_JSON() seems like just the thing.
> "Andres" == Andres Freund writes:
Andres> I'd vote for either 0) do nothing or 1). I think the use case
Andres> for specifying 64+ (or even 32+) columns in grouping is pretty
Andres> darn slim. And as you said, it's not that hard to work around
Andres> it if you need it, and that's only
On 21 May 2015 at 17:15, David Fetter wrote:
> On Thu, May 21, 2015 at 04:19:27PM +0100, Andrew Gierth wrote:
>> > "Dean" == Dean Rasheed writes:
>>
>> >> Consider that in both MSSQL 2014 and Oracle 12 the limit on the number
>> >> of arguments in a GROUPING() expression is ... 1.
>>
>> De
On Thu, May 21, 2015 at 12:21 PM, Andrew Gierth
wrote:
>> "David" == David Fetter writes:
>
> David> How about a more sensible data structure as a PG-specific addon.
> David> GROUPING_JSON() seems like just the thing.
>
> What exactly do you think it should return?
I vote for { "rube" : "g
> "David" == David Fetter writes:
David> How about a more sensible data structure as a PG-specific addon.
David> GROUPING_JSON() seems like just the thing.
What exactly do you think it should return?
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
On Thu, May 21, 2015 at 04:19:27PM +0100, Andrew Gierth wrote:
> > "Dean" == Dean Rasheed writes:
>
> >> Consider that in both MSSQL 2014 and Oracle 12 the limit on the number
> >> of arguments in a GROUPING() expression is ... 1.
>
> Dean> Actually Oracle haven't quite followed the stand
On 2015-05-21 16:19:27 +0100, Andrew Gierth wrote:
> True. It can handle more than 128 bits, even - I gave up trying after that.
>
> So. Options:
>
> 1) change GROUPING() to return bigint and otherwise leave it as is.
>
> 2) change GROUPING() to return numeric.
>
> 3) change GROUPING() so that
Andrew Gierth writes:
> So. Options:
> 1) change GROUPING() to return bigint and otherwise leave it as is.
> 2) change GROUPING() to return numeric.
> 3) change GROUPING() so that the result type varies with the number of
> args. I don't see anything in the spec that actually forbids this - it
> "Dean" == Dean Rasheed writes:
>> Consider that in both MSSQL 2014 and Oracle 12 the limit on the number
>> of arguments in a GROUPING() expression is ... 1.
Dean> Actually Oracle haven't quite followed the standard. They have 2
Dean> separate functions: GROUPING() which only allows 1
On 21 May 2015 at 09:20, Andrew Gierth wrote:
>> "Dean" == Dean Rasheed writes:
>
> >> Maybe INT8 would be a better choice than INT4? But I'm not sure
> >> there's any practical use-case for more than 30 grouping sets
> >> anyway. Keep in mind the actual output volume probably grows like
> "Dean" == Dean Rasheed writes:
>> Maybe INT8 would be a better choice than INT4? But I'm not sure
>> there's any practical use-case for more than 30 grouping sets
>> anyway. Keep in mind the actual output volume probably grows like
>> 2^N.
Dean> Actually using ROLLUP the output volu
On 20 May 2015 at 19:41, Tom Lane wrote:
> David Fetter writes:
>> While kicking the tires on the new GROUPING() feature, I noticed that
>> NUMERIC has no cast to bit(n). GROUPING() produces essentially a
>> bitmap, although the standard mandates for some reason that it be a
>> numeric type.
>
>
> "Tom" == Tom Lane writes:
>> I was thinking it should produce NUMERIC rather than int4 as it does
>> now in order to accommodate large numbers of columns, but the
>> usefulness of the bitmap is greatly increased if there's a simple
>> CAST to bit(n).
Tom> Maybe INT8 would be a better
David Fetter writes:
> While kicking the tires on the new GROUPING() feature, I noticed that
> NUMERIC has no cast to bit(n). GROUPING() produces essentially a
> bitmap, although the standard mandates for some reason that it be a
> numeric type.
> I was thinking it should produce NUMERIC rather
On Thu, Jul 4, 2013 at 7:53 PM, Atri Sharma wrote:
> On Thu, Jul 4, 2013 at 6:56 PM, Dev Kumkar
> wrote:
> > Ok, no problem. Will await for any other pointers regarding any related
> > patch here.
> >
> > Currently using UNION to archive similar results but looking if anything
> is
> > already d
On Thu, Jul 4, 2013 at 6:56 PM, Dev Kumkar wrote:
> On Thu, Jul 4, 2013 at 6:31 PM, Pavel Stehule
> wrote:
>>
>> Hello
>>
>>
>> I don't work on this topic now, and my code is not usable for production.
>
>
> Ok, no problem. Will await for any other pointers regarding any related
> patch here.
>
>
On Thu, Jul 4, 2013 at 6:31 PM, Pavel Stehule wrote:
> Hello
>
> I don't work on this topic now, and my code is not usable for production.
Ok, no problem. Will await for any other pointers regarding any related
patch here.
Currently using UNION to archive similar results but looking if anything
Hello
2013/7/4 Dev Kumkar :
> Hello,
>
> Am looking for the patch related to 'Implementation of GROUPING SETS'.
> Where can get this from?
>
> Related thread:
> http://www.postgresql.org/message-id/162867790905121420p7c910054x24d8e327abd58...@mail.gmail.com
>
I don't work on this topic now, and m
mber 19, 2011 10:45 PM
> To: edwbro...@gmail.com
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Grouping Sets
>
> Hello
>
> 2011/9/20 David Rinaldi :
>> Paul,
>>
>> I was able to apply the patch to 9.0.4 and so far looks good. My Oracle
>&g
40 hours or more like 5000 hours, in your estimate?
Thanks.
--
Regards
David
-Original Message-
From: Pavel Stehule [mailto:pavel.steh...@gmail.com]
Sent: Monday, September 19, 2011 10:45 PM
To: edwbro...@gmail.com
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Grouping Sets
h rep. 1 8000 0.8 80 80
> bmw germany 18000 15000 0.8333 83. 83
>
>
>
> Thanks
>
>
>
>
> --
> Regards
>
> David
>
>
> -Original Message-
> From: Pavel Stehule [mailto:pavel.steh...@gmail.com]
> Sent: Sunda
0.7143 71.4286 71
skoda czech rep. 1 80000.8 80 80
bmw germany 18000 15000 0.8333 83. 83
Thanks
--
Regards
David
-Original Message-
From: Pavel Stehule [mailto:pavel.steh...@gmail.com]
Sent: Sunday, September 18, 2011 2:34 PM
To: David
On Sun, Sep 18, 2011 at 02:08:01PM -0500, David Rinaldi wrote:
> I tried to apply the Grouping Sets Patch to 8.4, but received several Hunks
> failed messages, does anyone know if the failing hunks can be applied
> manually? Or what version they were applied to specifically?
Your best bet is prob
Hello
I have not any newest patch related to GROUPING SETS. The last version
of this patch is probably correct, but it is not well tested.
Actually, this patch has not quality to production usage :(. It is
just concept. You can test it.
Regards
Pavel Stehule
2011/6/18 Mariano Mara :
> Hi hacker
Hello
I found a break in GROUPING SETS implementation. Now I am playing with
own executor and planner node and I can't to go forward :(. Probably
this feature will need a significant update of our agg implementation.
Probably needs a some similar structure like CTE but it can be a
little bit reduc
2010/8/10 Joshua Tolley :
> On Mon, Aug 09, 2010 at 10:59:26PM +0200, Pavel Stehule wrote:
>> Hello
>>
>> I fixed an issues with empty sets. It just work, but there are some ugly
>> hacks.
>>
>> It's really needs own planner node - now grouping functions are not
>> supported by ORDER BY clause.
>
On Mon, Aug 09, 2010 at 10:59:26PM +0200, Pavel Stehule wrote:
> Hello
>
> I fixed an issues with empty sets. It just work, but there are some ugly
> hacks.
>
> It's really needs own planner node - now grouping functions are not
> supported by ORDER BY clause.
I haven't made it through the last
Hello
I was confused when I though so I found a solution of 1 shift/reduce conflict :(
All identificators used for buildin functions have to be a
col_name_keywords or reserved keyword. There is conflict with our
(probably obsolete) feature SELECT colname(tabname). So for this
moment the real solu
2010/8/7 Joshua Tolley :
> On Thu, Aug 05, 2010 at 04:46:51PM +0200, Pavel Stehule wrote:
>> I am sending a updated version.
>
> I've been looking at the changes to gram.y, and noted the comment under
> func_expr
> where you added CUBE and ROLLUP definitions. It says that CUBE can't be a
> reserve
On Thu, Aug 05, 2010 at 04:46:51PM +0200, Pavel Stehule wrote:
> I am sending a updated version.
I've been looking at the changes to gram.y, and noted the comment under
func_expr
where you added CUBE and ROLLUP definitions. It says that CUBE can't be a
reserved keyword because it's already used i
I found other issue :(
postgres=# select name, place from cars group by grouping sets(name, place,());
name | place
---+
bmw |
skoda |
opel |
| germany
| czech rep.
skoda | czech rep.
skoda | germany
bmw | czech rep.
bmw | germany
opel | czech rep
On Thu, Aug 05, 2010 at 04:46:51PM +0200, Pavel Stehule wrote:
> So Joshua, can you look on code?
Sure... thanks :)
--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com
signature.asc
Description: Digital signature
On Thu, Aug 05, 2010 at 06:21:18AM +0200, Pavel Stehule wrote:
> I hope, so next week you can do own work on this job - I am not a
> native speaker, and my code will need a checking and fixing comments
I haven't entirely figured out how the code in the old patch works, but I
promise I *can* edit c
2010/8/4 Joshua Tolley :
> On Wed, Aug 04, 2010 at 04:44:05AM +0200, Pavel Stehule wrote:
>> > Yeah, I seem to have done a poor job of producing the patch based on the
>> > repository I was working from. That said, it seems Pavel's working
>> > actively on
>> > a patch anyway, so perhaps my updati
On Wed, Aug 04, 2010 at 04:44:05AM +0200, Pavel Stehule wrote:
> > Yeah, I seem to have done a poor job of producing the patch based on the
> > repository I was working from. That said, it seems Pavel's working actively
> > on
> > a patch anyway, so perhaps my updating the old one isn't all that
2010/8/3 Joshua Tolley :
> On Tue, Aug 03, 2010 at 12:58:03PM -0700, David Fetter wrote:
>> On Mon, Aug 02, 2010 at 11:50:00PM -0600, Josh Tolley wrote:
>> > In case anyone's interested, I've taken the CTE-based grouping sets
>> > patch from [1] and made it apply to 9.1, attached. I haven't yet
>>
On Tue, Aug 03, 2010 at 12:58:03PM -0700, David Fetter wrote:
> On Mon, Aug 02, 2010 at 11:50:00PM -0600, Josh Tolley wrote:
> > In case anyone's interested, I've taken the CTE-based grouping sets
> > patch from [1] and made it apply to 9.1, attached. I haven't yet
> > done things like checked it f
On Mon, Aug 02, 2010 at 11:50:00PM -0600, Josh Tolley wrote:
> In case anyone's interested, I've taken the CTE-based grouping sets
> patch from [1] and made it apply to 9.1, attached. I haven't yet
> done things like checked it for whitespace consistency, style
> conformity, or anything else, but (
2010/8/3 Hitoshi Harada :
> 2010/8/3 Pavel Stehule :
>> Hello
>>
>> 2010/8/3 Joshua Tolley :
>>> In case anyone's interested, I've taken the CTE-based grouping sets patch
>>> from
>>> [1] and made it apply to 9.1, attached. I haven't yet done things like
>>> checked
>>> it for whitespace consiste
2010/8/3 Pavel Stehule :
> Hello
>
> 2010/8/3 Joshua Tolley :
>> In case anyone's interested, I've taken the CTE-based grouping sets patch
>> from
>> [1] and made it apply to 9.1, attached. I haven't yet done things like
>> checked
>> it for whitespace consistency, style conformity, or anything e
Hello
2010/8/3 Joshua Tolley :
> In case anyone's interested, I've taken the CTE-based grouping sets patch from
> [1] and made it apply to 9.1, attached. I haven't yet done things like checked
> it for whitespace consistency, style conformity, or anything else, but (tuits
> permitting) hope to fig
50 matches
Mail list logo