Return-Path: postarch
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA29573; Tue, 19 May 92 09:03:09 -0700
Message-Id: <9205191603.AA29573@postgres.Berkeley.EDU>
From: postarch (Postgres Mailing Archive)
Subject: Re: errors & append
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
Reply-To: mer@postgres.berkeley.edu
In-Reply-To: Your message of "Wed, 13 May 92 06:27:15 PDT."
             <9205131327.AA11989@postgres.Berkeley.EDU> 
Date: Tue, 19 May 92 09:01:48 PDT

you write:

> 1. Is there any way to trap errors such as back-end exits or failed
> attempts to connect to the back-end in this (or future versions) or can
> you point me at the relevant code to hack?

$POSTGRESHOME/src/lib/libpq/{fe-pqexec.c,portal.c}

> 2. It has been muted for quite a while that "append" will be modified to
> return the DB unique oid so that subsequent code can do something like
> "replace emp(sal=100000) where emp.oid=<value of oid just created>". My
> question is, does the query optimiser know that oid's are unique and
> hence there is no need to go scanning lots of relations for it ie. will
> the replace be efficient without an index on oids ?

The above query will translate to some sort of scan on emp.  It could
be either an index scan or a sequential scan depending on the existence of
indices (defined on emp.oid) and the size of the relation.


Jeff Meredith
mer@postgres.berkeley.edu