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.
