> "Robert" == Robert Haas 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 (irc:RhodiumTo
On Thu, Sep 19, 2013 at 12:52 PM, Andrew Gierth
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 (pgsql-hackers@postgresql.org
On Tue, Sep 17, 2013 at 2:27 PM, Andrew Gierth
wrote:
>> "Robert" == Robert Haas 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 pro
> "Robert" == Robert Haas 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 'WaitForBackgroundWorkerStartup':
b
On Sat, Sep 14, 2013 at 7:23 AM, Andrew Gierth
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 Haas
Enterpri
> "Peter" == Peter Eisentraut 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 (pgsql-hackers@postgresql.org)
To ma
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 [-Wma
Sent from my iPad
On 04-Sep-2013, at 21:38, Peter Eisentraut 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 updated
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:
http://www.postgresql.org/mailpref/pgs
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
‘check_ungrouped_colu
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 funct
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
"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, , VARIADIC "any") (
...
STYPE = ANYARRAY
...)
so the corresponding transi
Noah Misch 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
out that if you ma
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 transform
> 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 bette
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 v
On Thu, Jul 18, 2013 at 10:02 AM, David Fetter 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 must b
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
19 matches
Mail list logo
