In response to Christopher Browne <cbbrowne at ca.afilias.info>:

> Bill Moran <wmoran at collaborativefusion.com> writes:
> > 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?
> 
> I wouldn't think so; there's not much sensitivity to that data.
> 
> If you wanted to be paranoid, there, you might create a stored
> function to do the determination, and define it as a SECURITY DEFINER
> (e.g. - roughly equivalent to sudo).

That was the conclusion I came to after a good night's sleep :)

It's also easier for our existing upgrade process to manage, so it's
a win all around.

> > * 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)
> 
> There is a function, getLocalNodeId(); it's implemented in C, so it's
> not totally visible :-).

getLocalNodeId() works great, but it's only half of the equation.  What
I need is something like SELECT getLocalNodeId() = getSetOrigin([set#])
which will return true/false based on whether the current node is
the set origin or not.

That second procedure is the one that's missing, and it's the one I'm
creating now.  With security definer, it's pretty easy.

-- 
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran at collaborativefusion.com
Phone: 412-422-3463x4023