On 17.04.2006, at 5:18 Uhr, Michael Fuhr wrote:
Which way is "better" depends on your access patterns. PostgreSQL
doesn't support cross-database queries (except via functions like
dblink), so if you need to join tables in one database with tables
in another then you'll probably want make A, B,
Michael Fuhr escribió:
On Mon, Apr 17, 2006 at 09:42:59AM +0700, [EMAIL PROTECTED] wrote:
Now I have 3 database A,B,C is working in Interbase v 5.6,
but Interbas v 5.6 is no longger can hold what the client wants,
Sure ?
Before thinking to change the database, have you test firebird da
Hi Everyone,
I have installed postgresql 8.1.3.tar.gz. After compiling and
installing the postgresql is running fine but Im not able to install
tsearch2. I went under the postgresql source directory
/usr/local/postgresql8.1.3/contrib and then did a
#gmake all
#gmake install
After issuing these com
I just tried it going to contrib/tsearch2 folder and then did the following:makemake installIt created a tsearch2.so file in the lib directory of pgsql which is used while registering the tsearch2 functions. Make sure you have that .so file created under the lib folder of pgsql.
Hope this helps.../
Hello,
Is it possible to import a 8.1.1 dump file (standard format) into a
7.3.9 database?
I have an intranet with the most recent version and a public serveur
with selected data which is still running 7.3.
I am seeing an error with "\N"
Cheers
Tony
---(end of broadca
Hi
I have a cursor that fetches 150K rows and updates or
inserts a table with 150K rows.
It takes several minutes for the process to complete (about
15 minutes). The select by itself (without cursor) gets all rows in 15 seconds.
Is there a way to optimize the cursor to fetch all
"Shoaib Mir" wrote:
> I just tried it going to contrib/tsearch2 folder and then did the following:
>
> make
> make install
>
> It created a tsearch2.so file in the lib directory of pgsql which is used
> while registering the tsearch2 functions. Make sure you have that .so file
> created under the
Dunno, but it sounds like a "no" at a first sight.
What about dumping with INSERTS instead of COPY ?
That should work tho.
g.-
On 4/17/06, tony <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Is it possible to import a 8.1.1 dump file (standard format) into a
> 7.3.9 database?
>
> I have an intranet wit
Haven't seen this in previous discussions of OID wrap in the archives.
The issue is that DDL statements don't make any attempt to skip past
used ranges of OIDs.
duplicate key violates unique constraint "pg_attrdef_oid_index"
duplicate key violates unique constraint "pg_type_oid_index"
etc...
Whil
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Haven't seen this in previous discussions of OID wrap in the archives.
> The issue is that DDL statements don't make any attempt to skip past
> used ranges of OIDs.
> duplicate key violates unique constraint "pg_attrdef_oid_index"
If you can make that h
On Mon, Apr 17, 2006 at 14:38:24 +0200,
tony <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Is it possible to import a 8.1.1 dump file (standard format) into a
> 7.3.9 database?
>
> I have an intranet with the most recent version and a public serveur
> with selected data which is still running 7.3.
>
On Apr 17, 2006, at 2:46 PM, Tom Lane wrote:
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
Haven't seen this in previous discussions of OID wrap in the
archives.
The issue is that DDL statements don't make any attempt to skip past
used ranges of OIDs.
duplicate key violates unique constraint "pg
Jim Nasby <[EMAIL PROTECTED]> writes:
> Also, in 8.1, here's a list of tables in pg_catalog that don't appear
> to have unique constraints on oid... do these all look safe?
I'd be a bit surprised to find such a constraint on any of these,
seeing that they don't have oids.
13 matches
Mail list logo
