On Tue, Jan 02, 2001 at 02:27:28AM -0500, some SMTP stream spewed forth:
> Here is some code I played with before. It does what you want. Just make a
> new database to try it in.
Great, thanks.
I ended up working around it by storing one of the primary keys
in another table with some other inf
Here is some code I played with before. It does what you want. Just make a
new database to try it in.
-- Load the PGSQL procedural language
-- This could also be done with the createlang script/program.
-- See man createlang.
CREATE FUNCTION plpgsql_call_handler()
RETURNS OPAQUE AS '/
Is something like the following allowed (or is not a Bad Idea)?
table1
-+-
id1 |serial primary key
col2 |int references table2(id2)
table2
-+-
id2 |serial primary key
col2 |int references table1(id1)
Obviously,
While running the following set of statements:
create table category (
category_id serial not null primary key,
category_name text not null,
company_id int references company on delete cascade,
cattype_id int not null references cattype,
category_parent_id int not null references category
);
begi
I just noticed that the default order in the PATH to the postgres executable may
introduce
some unnecessary overhead when starting a process:
postmaster: ServerLoop:^I^Ihandling reading 4
postmaster: ServerLoop:^I^Ihandling reading 4
postmaster: ServerLoop:^I^Ihandling writing 4
postmaster: Back
Tom Lane wrote:
>
> The CVS logs show that a likely-looking patch was applied in Dec 1998,
> so 6.4.2 probably contains the fix. Update to 6.4.2 (maybe even just
> compile and install its pg_dump
Very cool. Just compiling and installing pg_dump from 6.4.2 was indeed sufficient to
fix
the issue
