Heikki...
> Then I edited wikidb-psql, changing those "public.tsvector" datatypes to
> just "tsvector". After that:
> psql wikidb < wikidb-psql
> And got no errors.
Okay, thanks! I hadn't removed the two instances of the schema
prepending the tsvector type. I can now import the data into
8.3b
On Sun, Oct 21, 2007 at 04:24:05PM -0400, Tom Lane wrote:
> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> > Perhaps we should include the functionality of that script in pg_dump.
>
> I'm pretty uncomfortable with the notion of having pg_dump deliberately
> throw data away. Another problem is
Tom Lane wrote:
> As for the datatype issue, I wonder whether we should just advise people
> to do
> CREATE DOMAIN public.tsvector AS pg_catalog.tsvector;
> before restoring?
Would be tidier in the long run to replace the references, but that's
simpler. Could we do that automatically to the
On CVS HEAD:
postgres=# SELECT a INTO foo1 from generate_series(1,100) a;
SELECT
postgres=# SELECT a INTO foo2 from generate_series(51,150) a;
SELECT
postgres=# DECLARE setopcur SCROLL CURSOR FOR SELECT * FROM foo1
intersect SELECT * FROM foo2;
server closed the connection unexpectedly
Th
Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Sun, Oct 21, 2007 at 04:24:05PM -0400, Tom Lane wrote:
>> I'm pretty uncomfortable with the notion of having pg_dump deliberately
>> throw data away. Another problem is that even if we did that, it would
>> only help people who dumped their old DB w
The following bug has been logged online:
Bug reference: 3691
Logged by: Maryz
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0-8.3b
Operating system: WinXP
Description:bug in pg_restore
Details:
In Postgres 8.0-8.2 and now 8.3b backup data in other schemas
Maryz wrote:
> The following bug has been logged online:
>
> Bug reference: 3691
> Logged by: Maryz
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.0-8.3b
> Operating system: WinXP
> Description:bug in pg_restore
> Details:
>
> In Postgres 8.0-8.2 and now
Please keep the list cc'd.
Mairambija wrote:
> On screen see only:
> pg_restore connecting to database for restore
>
> No any errors. And after this process no data on table.
>>> Restore:
>>> pg_restore.exe -h localhost -p 5432 -U postgres -a postgres --format=c
>> -a -i
>>> --disable-triggers
"Maryz" <[EMAIL PROTECTED]> writes:
> Restore:
> pg_restore.exe -h localhost -p 5432 -U postgres -a postgres --format=c -a -i
> --disable-triggers -t other.itm_blygis -v dmp\other.itm_blygis.out
pg_restore's -t switch doesn't do schemas. You need something like
-n other -t itm_blygis
in
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> TRAP: FailedAssertion("!(parse->utilityStmt == ((void *)0))", File:
> "prepunion.c", Line: 114)
> ISTM the Assertion is just bogus, and can be removed.
Good catch --- this used to be OK but I'd changed the parsetree
representation of DECLARE CURS
The following bug has been logged online:
Bug reference: 3692
Logged by: Bill Moran
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: FreeBSD
Description:Conflicting create table statements throw unexpected
error
Details:
(also occurs on 8
"Bill Moran" <[EMAIL PROTECTED]> writes:
> Issuing a statement like:
> CREATE TABLE table2 AS SELECT * FROM table1;
> simultaneously in two separate sessions should result in an error like
> "ERROR: relation "table2" already exists" (in one or the other of the
> sessions, depending on the exact ti
12 matches
Mail list logo
