On Tue, Sep 17, 2013 at 2:27 PM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
Robert == Robert Haas robertmh...@gmail.com writes:
Someone should do the same in WaitForBackgroundWorkerStartup so
that building with -Werror works.
Robert I don't get a warning there. Can you be more
On Thu, Sep 19, 2013 at 12:52 PM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
It compiles without error and looks ok...
Thanks for checking. Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list
Robert == Robert Haas robertmh...@gmail.com writes:
bgworker.c: In function 'WaitForBackgroundWorkerStartup':
bgworker.c:866: warning: 'pid' may be used uninitialized in this function
Robert Does the attached patch fix it for you?
It compiles without error and looks ok...
--
Andrew
On Sat, Sep 14, 2013 at 7:23 AM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
Peter Please fix compiler warnings:
Someone should do the same in WaitForBackgroundWorkerStartup so that
building with -Werror works.
I don't get a warning there. Can you be more specific about the problem?
Robert == Robert Haas robertmh...@gmail.com writes:
Someone should do the same in WaitForBackgroundWorkerStartup so
that building with -Werror works.
Robert I don't get a warning there. Can you be more specific about
Robert the problem?
bgworker.c: In function
Peter == Peter Eisentraut pete...@gmx.net writes:
Peter Please fix compiler warnings:
Someone should do the same in WaitForBackgroundWorkerStartup so that
building with -Werror works.
New patch coming shortly.
--
Andrew.
--
Sent via pgsql-hackers mailing list
On Fri, 2013-09-13 at 14:56 +0530, Atri Sharma wrote:
This is our complete patch for implementation of WITHIN GROUP.
Please fix compiler warnings:
inversedistribution.c: In function ‘mode_final’:
inversedistribution.c:276:11: warning: ‘mode_val’ may be used uninitialized in
this function
On 7/19/13 11:59 AM, Atri Sharma wrote:
Hi all,
This is our current work-in-progress patch for WITHIN GROUP.
This patch needs to be rebased.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Sent from my iPad
On 04-Sep-2013, at 21:38, Peter Eisentraut pete...@gmx.net wrote:
On 7/19/13 11:59 AM, Atri Sharma wrote:
Hi all,
This is our current work-in-progress patch for WITHIN GROUP.
This patch needs to be rebased.
This version of patch is quite old.We will be sending an
On Fri, 2013-07-19 at 21:29 +0530, Atri Sharma wrote:
Hi all,
This is our current work-in-progress patch for WITHIN GROUP.
Please fix these compiler warnings:
parse_agg.c: In function ‘check_ungrouped_columns_walker’:
parse_agg.c:848:3: warning: passing argument 1 of
On Wed, Jul 24, 2013 at 04:16:28AM +, Andrew Gierth wrote:
Noah Misch said:
Other aggregates based on this syntax might not desire such type
unification.
Then there would have to be some way to distinguish that. Maybe those could
have -1 and the standard hypothetical set functions
On Tue, Jul 23, 2013 at 01:21:52AM +, Andrew Gierth wrote:
For hypothetical set functions we add a special case, aggordnargs=-1,
for which both the aggregate and the finalfn must be defined as
(variadic any) and parse analysis detects this case and unifies the
types of the normal args with
some Salesforce folks that would be me! It looks like I didn't quite
communicate to Tom just what I was looking for as I do indeed want to have
a variable number of any types, as:
CREATE AGGREGATE FOO ( ANYELEMENT, more types, VARIADIC any) (
...
STYPE = ANYARRAY
...)
so the corresponding
Andrew,
Well, as you probably know, the spec is a whole pile of random
special-case syntax and any similarities are probably more accidental
than anything else.
Hah, I didn't realize that our ordered aggregate syntax even *was* spec.
A major difference is that in agg(x order by y), the
The problem is, given that the parser is looking at:
foo(p1,p2,...) within group (order by q1,q2,...)
how do we best represent the possible matching functions in pg_proc
and pg_aggregate? Our partial solution so far does not allow
polymorphism to work properly, so we need a better way;
On Thu, Jul 18, 2013 at 10:33:15PM +, Andrew Gierth wrote:
Josh Berkus wrote:
Well, seems like it would work the same as
agg_func(constx,coly,colz ORDER BY coly, colz)
I'd try transforming WITHIN GROUP into the above during parse analysis. The
default would be the transformation
Noah Misch n...@leadboat.com writes:
(I don't know whether VARIADIC transition functions work today, but that would
become an orthogonal project.)
Coincidentally enough, some Salesforce folk were asking me about allowing
VARIADIC aggregates just a few days ago. I experimented enough to find
On Thu, Jul 18, 2013 at 03:15:14AM +, Andrew Gierth wrote:
The spec defines two types of aggregate function classed as ordered set
function, as follows:
1. An inverse distribution function taking one argument (which must be
a grouped column or otherwise constant within groups) plus a
On Thu, Jul 18, 2013 at 10:02 AM, David Fetter da...@fetter.org wrote:
On Thu, Jul 18, 2013 at 03:15:14AM +, Andrew Gierth wrote:
The spec defines two types of aggregate function classed as ordered set
function, as follows:
1. An inverse distribution function taking one argument (which
19 matches
Mail list logo
