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 t
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 wonde
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
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 whet
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 th
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
"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
EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, November 10, 2003 2:41 AM
Subject: Re: [GENERAL] Temp rows - is it possible?
> I found one way to do by combining temporary table and inhertis.
> Temporary table will automatically dropped when disconnects, and
> table
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) follow
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 ar
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
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
-
12 matches
Mail list logo