Re: OID wraparound (was Re: pg_depend)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: OID wraparound (was Re: pg_depend)
Date: 2001-07-19 17:19:25
Message-ID: 24145.995563165@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
> At 00:00 19/07/01 -0400, Tom Lane wrote:
>> INSERT INTO foo ... RETURNING x,y,z,...

> That would have been me; at the time we also talked about
> UPDATE...RETURNING and Jan proposed allowing UPDATE...RETURNING
> {[Old.|New.]Attr,...}

Hm. I'm less excited about UPDATE ... RETURNING since it would seem
that SELECT FOR UPDATE followed by UPDATE would get that job done
in a somewhat-less-nonstandard manner. But anyway ---

Thinking about this some more, it seems that it's straightforward enough
for a plain INSERT, but I don't understand what's supposed to happen if
the INSERT is replaced by an ON INSERT DO INSTEAD rule. The rule might
not contain an INSERT at all, or it might contain several INSERTs into
various tables with no simple relationship to the original. What then?

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mike Cianflone 2001-07-19 17:20:47 Turning off revision tracking so vacuum never needs to be run
Previous Message Mark Volpe 2001-07-19 17:13:44 Re: [PATCHES] Re: [PATCH] Re: Setuid functions