| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
| Cc: | darcy(at)druid(dot)net (D'Arcy J(dot)M(dot) Cain), Michael J Schout <mschout(at)gkg(dot)net>, Alessio Bragadini <alessio(at)albourne(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Insert..returning (was Re: Re: postgres TODO) |
| Date: | 2000-07-12 16:47:11 |
| Message-ID: | 23124.963420431@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:
>> I think the thing he has in mind is the situation where one has insert
>> perms but not select.
Exactly --- and that's a perfectly reasonable setup in some cases (think
blind mailbox). INSERT ... RETURNING should require both insert and
select privileges IMHO.
> I would be inclined to follow the perms; is there a problem with that? You
> should not let them read the row they inserted since it *may* contain
> sensitive (automatically generated) data - the DBA must have had a reason
> for preventing SELECT.
It would be a pretty stupid app that would be using INSERT ... RETURNING
to obtain the data that it itself is supplying. The only reason I can
see for the feature is to get hold of automatically-generated column
values. Thus, obeying select permissions is relevant.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ross J. Reedstrom | 2000-07-12 16:48:24 | Re: 7.0.2 issues / Geocrawler |
| Previous Message | Ross J. Reedstrom | 2000-07-12 16:36:44 | Re: 7.0.2 issues / Geocrawler |