| From: | Stephen Frost <sfrost(at)snowman(dot)net> |
|---|---|
| To: | Greg Stark <gsstark(at)mit(dot)edu> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: leaky views, yet again |
| Date: | 2010-10-05 18:15:20 |
| Message-ID: | 20101005181520.GK26232@tamriel.snowman.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
* Greg Stark (gsstark(at)mit(dot)edu) wrote:
> Though I find it unlikely the sales people would have direct access to
> run arbitrary SQL -- let alone create custom functions.
I'm not really sure why..? Perhaps not quite the same, but I've got
quite a few users who have direct SQL access (though they use ODBC on
their side, typically, there's nothing which forces them to) and I'd
certainly like to have the views that I've created which do row-level
filtering work correctly. It's not to the point where I've started
using set-returning functions, but it's really not a situation I like
being in. :/
> If the users that have select access on the view don't have DDL access
> doesn't that make them leak-proof for those users?
Yeah.. I feel like we 'fixed' that whole problem with DO in any case..
Thanks,
Stephen
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2010-10-05 18:20:52 | Re: leaky views, yet again |
| Previous Message | Greg Stark | 2010-10-05 18:08:15 | Re: leaky views, yet again |