From: | Matthew Horoschun <mhoroschun(at)canprint(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Controlling access to Sequences |
Date: | 2003-02-01 04:28:00 |
Message-ID: | 8BB55A7D-359D-11D7-92E5-000393B3A702@canprint.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Hi Tom,
Thanks for the response.
On Saturday, February 1, 2003, at 03:09 PM, Tom Lane wrote:
> Matthew Horoschun <mhoroschun(at)canprint(dot)com(dot)au> writes:
>> My understanding is that I need to GRANT the UPDATE privilege on the
>> SEQUENCE if I want a user to be able to to use nextval() on it. The
>> trouble is, if they can do a nextval() they can also do a setval()
>
> So? With enough time on your hands, you can apply nextval() often
> enough to get from any point A to any point B. It seems illusory
> to think that forbidding setval() makes things more secure.
Absolutely, You're right. nextval() is just as troublesome.
I don't want to arbitrarily restrict access to setval(). I just want a
safer way of handling automatic allocation of primary keys on certain
tables.
Should I just avoid SEQUENCES altogether and use the OIDs under normal
circumstances and the MAX( id ) + 1 style thing when I need a
human-usable number?
Matthew.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-02-01 04:43:22 | Re: Controlling access to Sequences |
Previous Message | Tom Lane | 2003-02-01 04:09:31 | Re: Controlling access to Sequences |