> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers