Michael C Rosenstein <m...@mdibl.org> writes:
> For example webAppUser sometimes needs to access the
> public1.get_customer_name() function, the public1.order table and the
> edit.account table. After a new data load of the public2 database, the
> webAppUser would need to access the public2.get_customer_name()
> function, the public2.order table and the edit.account table. By
> switching the webAppUser's 'get_customer_name()' and 'account' synonyms,
> this toggling between accessing public1 and public2 objects is quick,
> easy and seamless. The webAppUser code need only contain:
> select get_customer_name();
> or
> select * from order;
> without needing to be conscious of whether it is selecting from public1
> or public2.
> Synonyms are a great feature in Oracle. The lack of synonyms in
> PostgreSQL was one of our biggest hesitations in switching. As I said,
> however, we found a hacky workaround by toggling the webAppUser's search
> path.
[ shrug... ] Beauty is in the eye of the beholder, I guess. To me the
search_path change seems like the natural way to do that, and flipping a
mess of synonyms the hack. What happens when you miss one synonym?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
