Re: Do we want SYNONYMS?

> [ 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?

Changing Oracle synonyms is completely scriptable using the data
dictionary, so we never miss setting a synonym ;)

For the most part, search_path works great for us, but not in situations
in which some target objects are in one database, and other target
objects are in another database but have overlapping names with the
first database

For example, given the following three databases, the 'webAppUser"
end-user may need--transparently, i.e., without using dot notation--to
access the public1.get_bar() function and the edit1.customer table.

public1 DB
----------
get_foo()
customer (table)

public2 DB
----------
get_foo()
customer (table)

edit1 DB
--------
customer (table)

edit2 DB
--------
customer (table)

Setting its search_path to 'public1,edit1' works fine for the get_foo()
function, but not for the customer table.

I linked to the Oracle documentation not to suggest that Postgres must
implement exactly that, but to help convey exactly what I'm talking
about viz 'synonyms'.

I'd be glad to talk off-line w/ someone about the value of this feature,
but I'm not religious about it (and it's likely I don't know enough
about Postgres yet to find a more elegant solution).

Overall, we're very very very happy with Postgres, and excited that next
week we will be going live with our Postgres-converted web app (and
joyously dumping Oracle)!

/m