abbreviations, not just whether 'infinity' crashes.
>
> regards, tom lane
>
--
Daniel Grace
AGE, LLC
System Administrator and Software Developer
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
The following bug has been logged online:
Bug reference: 6005
Logged by: Daniel Grace
Email address: dgr...@wingsnw.com
PostgreSQL version: 9.1-beta1
Operating system: Win7 x64 (x86 postgres)
Description:ALTER ROLE ... VALID UNTIL 'infinity' crashes postm
The following bug has been logged online:
Bug reference: 5987
Logged by: Daniel Grace
Email address: dgr...@wingsnw.com
PostgreSQL version: 9.1-alpha5
Operating system: Win7 x64
Description:Rows created by WITH (INSERT ... RETURNING) are not
visible to the rest of
The following bug has been logged online:
Bug reference: 5985
Logged by: Daniel Grace
Email address: thisgenericn...@gmail.com
PostgreSQL version: 9.1a5
Operating system: Win7 x64, also seen on Debian
Description:CLUSTER ... USING can fail with ERROR: index xxx does
h of these conditions are true, discard one subplan and
rewrite all references to point to the other one?
Assuming it IS possible, are there any particular situations where it
wouldn't work?
On Mon, Oct 4, 2010 at 11:47 AM, Robert Haas wrote:
> On Mon, Sep 27, 2010 at 5:09 PM, Daniel Grace
The following bug has been logged online:
Bug reference: 5688
Logged by: Daniel Grace
Email address: dgr...@wingsnw.com
PostgreSQL version: 9.0.0
Operating system: Windows XP 32-bit
Description:ALTER TABLE ALTER col TYPE newtype fails if col is named
in an UPDATE OF
> Index Scan using child_pkey on wings_sky.child c (cost=0.00..40.10
rows=20 width=8)
Output: c.parent_id, c.v1, c.v2
Index Cond: (c.parent_id = $0)
Is there any chance this might be looked at in a future release?
--
Daniel Grace
AGE, LLC
System Administrator and Software Developer
dgr...@wingsnw
On Fri, Jul 23, 2010 at 10:42 AM, Alex Hunsaker wrote:
> On Fri, Jul 16, 2010 at 18:04, Daniel Grace wrote:
>> However, in some circumstances Postgres will fail
>
> How exactly?
>
> Maybe its so obvious I missed it?
>
Please see BUG #5564 -- I accidentally submitt
The following bug has been logged online:
Bug reference: 5564
Logged by: Daniel Grace
Email address: dgr...@wingsnw.com
PostgreSQL version: 9.0beta3
Operating system: Windows XP 32-bit
Description:Odd behavior with aggregate_func(DISTINCT foo ORDER BY
foo)
Details
The following bug has been logged online:
Bug reference: 5563
Logged by: Daniel Grace
Email address: dgr...@wingsnw.com
PostgreSQL version: 9.0beta3
Operating system: Windows XP 32-bit
Description:Odd behavior with aggregate_func(DISTINCT foo ORDER BY
foo)
Details
On Thu, Jul 8, 2010 at 10:52 PM, Tom Lane wrote:
> "Daniel Grace" writes:
>> I apologize for not including detailed schema information. It took a lot to
>> get this to reduce to the point it did, and hopefully this is enough
>> information to find a bug.
>
The following bug has been logged online:
Bug reference: 5548
Logged by: Daniel Grace
Email address: dgr...@wingsnw.com
PostgreSQL version: 9.0beta2
Operating system: Windows XP 32-bit
Description:ERROR: invalid attnum ## for rangetable entry on
EXPLAIN VERBOSE, not
On Sat, Apr 25, 2009 at 9:52 AM, Tom Lane wrote:
> Daniel Grace writes:
> > The following nonsensical query causes PostgreSQL to fail with ERROR:
> plan
> > should not reference subplan's variable. (This was stripped down from an
> > 'useful' que
ame id (can that actually happen?
> Maybe there's more wrong with this query...), because what you
> wrote is a scalar sub-SELECT inside an aggregate call that belongs
> to the outermost query.
>
>regards, tom lane
>
--
Daniel Grace
AGE, LLC
System Administrator and Software Developer
dgr...@wingsnw.com // (425)327-0079 // www.wingsnw.com
On Fri, Apr 24, 2009 at 5:38 PM, Tom Lane wrote:
> Daniel Grace writes:
> > The following nonsensical query causes PostgreSQL to fail with ERROR:
> plan
> > should not reference subplan's variable. (This was stripped down from an
> > 'useful' que
The following nonsensical query causes PostgreSQL to fail with ERROR: plan
should not reference subplan's variable. (This was stripped down from an
'useful' query that triggered the same bug). First encountered on 8.3.4,
reproduced on 8.3.7
BEGIN;
CREATE SCHEMA bug_schema;
SET SEARCH_PATH='bug_
16 matches
Mail list logo
