> Well, porting applications from other database systems that support synonyms
> (i.e. Oracle, DB2, SQL Server).
SQL Server supports synonyms? If it's not Oracle-only, it's a more
powerful argument to have the feature.
(IMHO, the main reason why Oracle has synonyms is that their
implementation of SCHEMA is broken.)
There are two more arguments for table synonyms:
1. to support application versioning with an easier syntax than
updatable views.
2. to provide an alternative to the difficult-to-manage search_path
However, the latter does mean that there needs to be a fixed
order-of-resolution for synonyms which conflict with the name of objects
in other schema. And one which doesn't break backwards compatiblity.
I'd love to hear from someone at EDB: how are you dealing with synonym
name collisions right now?
> Is this the feature the community would benefit from? We can consider adding
> column synonyms if we won't hardwire synonyms to pg_class objects.
Actually, we'd just put that one in pg_attribute. I worked out a
back-of-the-napkin design, and it wouldn't require any new tables. A
new column, yes. But no new catalog tables.
So, I don't support your idea of having a completely separate catalog.
Sorry.
The use case for simple column synonyms is supporting application
versioning by allowing changes to column names without needing to
refactor all applications. Later, we could also implement "calculated
columns" where the synonym points to an expression rather than a direct
column link. All sorts of use cases for that.
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com
