On Thu, Oct 2, 2008 at 3:24 AM, Bill Moran
<wmoran at collaborativefusion.com>wrote:

>
> I'm trying to do this:
> SELECT set_origin FROM sl_set
>
> which works fine _IF_ I have superuser privs, but I need normal users
> to be able to query the database to see if they're talking to a master
> or a slave system (I know there are other ways to do this, such as
> BEGIN; DELETE FROM replicated_table; ROLLBACK, but those methods
> generate tons of errors that flood our error management systems, and
> then require all sorts of other complexity to manage)
>
> Before I issue a GRANT to allow select rights on that table to anyone
> who tries, my questions are:
> * Is there any inherent danger in allowing SELECT on that table to
>  normal users?
> * Is there a better way (I looked for a store procedure, such as
>  getlocalnodeid(), but if it exists, I'm not seeing it in the docs)


I am no expert on security, Slony or Slony+security, but it seems harmless
to allow public SELECT on one of the tables if it solves your problem. But
take due care that none of other commands (INSERT/UPDATE/DELETE/TRUNCATE)
are executable by a normal user on this table.

Best regards,

-- =

gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | indiatimes | yahoo }.com

EnterpriseDB      http://www.enterprisedb.com

Mail sent from my BlackLaptop device
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20081002/=
584b7be4/attachment.htm