Jeff Davis writes:
> On Tue, 2011-07-12 at 11:20 -0400, Tom Lane wrote:
>> So far as I can see, the failure only
>> occurs if we have a plain (non-grouping) Agg node, which implies that
>> the user is trying to use windowing functions on a result set that's
>> guaranteed to contain exactly one agg
Angel Dabov wrote:
>
> The following bug has been logged online:
>
> Bug reference: 6102
> Logged by: Angel Dabov
> Email address: o...@ustrem.org
> PostgreSQL version: JDBC 8.3
> Operating system: Windows
> Description:JDBC BIND Source IP Address
> Details:
>
> Hi,
"Luc Filiatrault" writes:
> Description:Two similar object giving slightly different results
There's not much anyone can do about this report without a specific,
concrete test case to work with -- that means test data not only a query;
see http://wiki.postgresql.org/wiki/Guide_to_reportin
The following bug has been logged online:
Bug reference: 6115
Logged by: Luc Filiatrault
Email address: lucfiliatra...@videotron.ca
PostgreSQL version: 8.4.8
Operating system: (Debian 4.4.5-8) 4.4.5, 32-bit (Squeeze2)
Description:Two similar object giving slightly d
On Tue, 2011-07-12 at 11:20 -0400, Tom Lane wrote:
> So far as I can see, the failure only
> occurs if we have a plain (non-grouping) Agg node, which implies that
> the user is trying to use windowing functions on a result set that's
> guaranteed to contain exactly one aggregated row. That seems p
Excerpts from Tom Lane's message of mar jul 12 11:20:39 -0400 2011:
> I wrote:
> > ... so I guess the answer is that this code ought to avoid adding Vars that
> > are only mentioned within aggregates.
>
> The cleanest way to fix this would involve adding another flag parameter
> to flatten_tlist a
I wrote:
> ... so I guess the answer is that this code ought to avoid adding Vars that
> are only mentioned within aggregates.
The cleanest way to fix this would involve adding another flag parameter
to flatten_tlist and pull_var_clause. This is no problem to do in HEAD
or even 9.1, but I'm a bit
"Wiesiek" wrote:
> Description:Bad path
> When I try to backup i have a problem.
> \"alfaCC2\"
> I have to do the backup manually from the console and correct
> entry.
"Manually from the console" as opposed to what?
What "entry" do you correct? In what way?
> Where can improve
Jeff Davis writes:
> In branch postgresql/master:
> SELECT SUM(SUM(a)) OVER ()
> FROM (SELECT NULL::int4 AS a WHERE FALSE) R;
> ERROR: XX000: cannot extract attribute from empty tuple slot
Huh, interesting.
> Honestly, I'm not sure what the semantics of that are supposed to be. Is
> it even al
The following bug has been logged online:
Bug reference: 6114
Logged by: Wiesiek
Email address: wu...@wp.pl
PostgreSQL version: PG ADMIN 1.12.2
Operating system: Win2k3, Win2k8
Description:Bad path
Details:
When I try to backup i have a problem.
\"alfaCC2\"
I have t
Trying to exclude items from dumps of postgis-enabled databases
we use pg_restore -l output and strip what we think belong to PostGIS.
In doing so, Renzo found that for OPERATOR there are not enough
informations to unambiguosly find it being part of PostGIS (see
included mail snippet).
Do you thi
Hello,
=# select extract(epoch from 'infinity'::timestamp);
date_part
---
0
A better value would be 'infinity'::float8. Ditto for -infinity.
I'm trying to use a box-based index to represent the intervals in a
table containing a pair of fields date_from, date_to (timestamps),
wh
--On 12. Juli 2011 04:32:11 + David Carlos Manuelda
wrote:
The following bug has been logged online:
Bug reference: 6113
Logged by: David Carlos Manuelda
Email address: stormb...@gmail.com
PostgreSQL version: 9.0.4
Operating system: Gentoo Linux
Description:
13 matches
Mail list logo
