Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
We recently decided we had to forbid foreign-key references from temp
tables to permanent tables because of this effect. I wonder whether
we won't end up forbidding temp tables as children of permanent tables
too.
Mattias Kregert [EMAIL PROTECTED] writes:
This is great!
create table a(...);
insert into a(...); # fixed values
create table b() inherits (a);
insert into b values(...); # temporary values
select * from a; # You can get both global and temporary values.
I don't think it's actually
Tom Lane wrote:
Mattias Kregert [EMAIL PROTECTED] writes:
This is great!
create table a(...);
insert into a(...); # fixed values
create table b() inherits (a);
insert into b values(...); # temporary values
select * from a; # You can get both global and temporary values.
I
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
We recently decided we had to forbid foreign-key references from temp
tables to permanent tables because of this effect. I wonder whether
we won't end up forbidding temp tables as children of permanent tables
too.
Yep, I think we will
Hello Bruce,
Monday, November 10, 2003, 11:08:47 AM, you wrote:
BM Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
We recently decided we had to forbid foreign-key references from temp
tables to permanent tables because of this effect. I wonder whether
we won't
Tom,
On Mon, 10 Nov 2003 09:39:32 -0500
Tom Lane [EMAIL PROTECTED] wrote:
select * from a; # You can get both global and temporary values.
I don't think it's actually reliable. B was meant to be a temp table,
right?
Ugh Yes.
create *temp* table b() inherits (a);
--
TANIDA Yutaka
On Tuesday 11 November 2003 02:16, Robert Creager wrote:
When grilled further on (Mon, 10 Nov 2003 09:39:32 -0500),
Tom Lane [EMAIL PROTECTED] confessed:
We recently decided we had to forbid foreign-key references from temp
tables to permanent tables because of this effect. I wonder
What you really want is an end of session callback.
There is not one in PostgreSQL. However, if this is
for session management, you can handle this in your
application by bracketing the connection code with
the table management.
That is, in your app (or rather in your session pooling
code)
Hello pgsql-general,
I'm trying to implement a table with rows that are automatically
deleted when the session that inserted them disconnects, sort of like
our own alternative to pg_stat_activity. Is it possible and what
approach should I be trying to achieve such a thing?
Thanks!
--
-Boris
Hello Dennis,
Friday, November 7, 2003, 1:29:32 PM, you wrote:
DG Boris Popov wrote:
Hello pgsql-general,
I'm trying to implement a table with rows that are automatically
deleted when the session that inserted them disconnects, sort of like
our own alternative to pg_stat_activity. Is it
If the table doesn't have to be 100% accurate, you could always timestamp
the rows and have connected clients update their row, while old rows get
reaped periodicaly.
On Fri, 7 Nov 2003, Boris Popov wrote:
I do want them to be visible to everybody. This is a sessions pool,
where sessions are
11 matches
Mail list logo
