"Marko Tiikkaja" writes:
> While playing around with common table expressions, I found this:
> => with cte(foo) as ( values(0) ) values((select foo from cte));
> ERROR: XX000: SubPlan found with no parent plan
Oh, interesting, thanks for the bug report!
> In src/backend/executor/nodeValuesscan
Thanks for the quick reply, Tom. That makes sense, and yes, that does
appear to be the problem.
I thought that I *was* using the newer pg_dump, but I'm doing this on
Debian:
# su - postgres -c "env PGCLUSTER=8.3/main pg_dump openx|env
PGCLUSTER=8.4/main pg_restore -d template1 -C"
And t
The following bug has been logged online:
Bug reference: 4902
Logged by: Marko Tiikkaja
Email address: marko.tiikk...@cs.helsinki.fi
PostgreSQL version: 8.4.0
Operating system: Linux
Description:Subquery in VALUES referencing a CTE
Details:
While playing around with
Greg Stark writes:
> On Sun, Jul 5, 2009 at 4:28 PM, Tom Lane wrote:
>> This is not a bug, it's the intended behavior.
> I thought that was a bug, just one that was too hard to fix for the
> problems it caused. It might be more fixable if we get around to the
> work that was discussed earlier whe
On Sun, Jul 5, 2009 at 5:10 PM, Greg Stark wrote:
> On Sun, Jul 5, 2009 at 4:28 PM, Tom Lane wrote:
>> when i done dump->restore i
>>> have surprise,
>>> Column ordering was changed.
>>
>> This is not a bug, it's the intended behavior.
>
> I thought that was a bug
Rereading the thread I'll also me
On Sun, Jul 5, 2009 at 4:28 PM, Tom Lane wrote:
> when i done dump->restore i
>> have surprise,
>> Column ordering was changed.
>
> This is not a bug, it's the intended behavior.
I thought that was a bug, just one that was too hard to fix for the
problems it caused. It might be more fixable if we
"Steve Purcell" writes:
> The DB schema for openx (openx.org) contains a table with a column called
> "window", which now causes a syntax error if unquoted. pg_dump doesn't
> quote the column, so pg_restore/psql fail on the pg_dump output.
This is one of the reasons why it's recommended that you
The following bug has been logged online:
Bug reference: 4901
Logged by: Steve Purcell
Email address: st...@sanityinc.com
PostgreSQL version: 8.4.0
Operating system: Linux (Debian Unstable)
Description:Column name "window" breaks pg_dump/pg_restore
Details:
The DB s
"Peter Headland" writes:
> While noodling around some more, I found that a comparison to '()'
> allows use of the index, as does '(abc)' and even '(a(b(c)d)e)'. It
> appears that mismatched open/close paren pairs trigger the
> bug. Obviously something is parsing the string literal and mishandling
Oleg Serov writes:
> If i have tables with inherits, and the
> n i adding a column in to the base table, the new column will be at
> the on of column list in child table, but when i done dump->restore i
> have surprise,
> Column ordering was changed.
This is not a bug, it's the intended behavior.
In installing I get an error message "Failed to set permissions on the
installed files.? Please see the login file in 'c:\Program
Files\PostgreSQL\8.3\tmp\pgperm.log'."
This file does not exist (it doesn't appear in explorer).
What do I need to do to get this to install?
On Sunday 05 July 2009 03:03:00 Peter Headland wrote:
> The following bug has been logged online:
>
> Bug reference: 4899
> Logged by: Peter Headland
> Email address: pheadl...@actuate.com
> PostgreSQL version: 8.4.0
> Operating system: Windows
> Description:Open parent
Here is the solution of this problem:
Patch
src/bin/pg_dump/pg_dump.c
appendPQExpBuffer(q, "CREATE TABLE %s (",
fmtId(tbinfo->dobj.name));
actual_atts = 0;
for (j = 0; j < tbinfo->numatts; j++)
{
/* Is this one of the table's own attrs, and not dropped ? */
- if (!tbinfo->inhAttrs[j] &&
- (!tbinfo
No, we can't do like this, because we have something like this:
CREATE TABLE test_base (
id INT
);
CREATE TABLE test_child_with_data (
t TEXT
) INHERITS (test_base);
ALTER TABLE test_base ADD COLUMN date DATE;
INSERT INTO test_child_with_data VALUES (1, 'text', NOW());
CREATE FU
While noodling around some more, I found that a comparison to '()' allows use
of the index, as does '(abc)' and even '(a(b(c)d)e)'. It appears that
mismatched open/close paren pairs trigger the bug. Obviously something is
parsing the string literal and mishandling parentheses. I don't understand
The following bug has been logged online:
Bug reference: 4900
Logged by: Peter Headland
Email address: pheadl...@actuate.com
PostgreSQL version: 8.4.0
Operating system: Windows
Description:Query planner misses obvious optimization on ordered
UNION DISTINCT
Details:
The following bug has been logged online:
Bug reference: 4899
Logged by: Peter Headland
Email address: pheadl...@actuate.com
PostgreSQL version: 8.4.0
Operating system: Windows
Description:Open parenthesis breaks query plan
Details:
In a moderate-size table (~400,00
17 matches
Mail list logo
