Re: [HACKERS] Get OID of just inserted record

Thus spake Aaron J. Seigo
> > Just wondering, how would you handle insert only tables?  That is, you
> > have insert privleges but not select.  Would you still return the field
> > or fields requested surprising the database designer, accept the insert
> > but return an error or refuse the insert entirely since the task could
> > not be completed?
> 
> i think the task should be refused in entirety so as not to cause unexpected
> results. performing insert/select tasks would require more permissions to
> the system in general than someone just wanting to do an insert, but that is not
> unusual in any way and should be expected... 

Exactly.  The reason I ask my question is that in PyGreSQL I already fake
this behaviour by doing a select * immediately after an insert and if it
succeeds I load the caller's dictionary with the data so that they have
the oid and any triggered or defaulted fields.  This function would be
useful for me except that I have to be able to deal with tables with
insert only access and still let the insert go through.  My problem is
that it is a generic function so I can't hard code the decision and need
to have some way to check each time.

> as you mentioned, i haven't seen this anywhere else, ... how
> much use would it get? well. i know i'd use it if it were available.. i use
> triggers/rules, procedures and external code to do what i need now.. so
> "sub-inserts" (as you aptly called them) wouldn't really push the bounds of
> what is possible, but i think they would push the bounds of what is easily and
> dependly possible. 

I hope we also allow the following if we do it.

INSERT INTO foo VALUES (1, 'aaa') RETURN f1, f2;

or

INSERT INTO foo VALUES (1, 'aaa') RETURN *;

> my 0.02 (and that's canadian.. so..)

Dollarettes?
Dollar Lite?

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.