Andy Colson <andy@xxxxxxxxxxxxxxx> writes: > Can someone post what the synonyms will do? And what will be synonym'able? > (cuz JD said: SYNONYMS work for things that aren't a table. > then tgl said: synonyms for non-table things was pretty much rejected. Well, to clarify: what was shot down IMO was the proposed implementation with a separate catalog, which would have to be added to the lookup rules for every kind of object, in particular complicating the resolution rules for overloaded operators/functions even more than they already are. The simple fallback that we discussed was adding another "relkind" to pg_class entries, so that you could have a pg_class row that was just a reference to another one. That wouldn't introduce any new lookup complexity, because the synonym entry would be just like others (in particular, you couldn't have a synonym with exactly the same schema name + relname as some other pg_class row, so it adds no new ambiguity). But it would only provide synonyms for denizens of pg_class, ie, tables, views, sequences, indexes. Now, if there's really interest in synonyms for functions and so on, you could imagine extending the definitions of other system catalogs such as pg_proc to similarly allow alias entries in them. But it'd be a significant amount of work for each object type you wanted synonyms for, so you'd need to provide a convincing use-case for each one. So far, the plausible use-cases I've heard were just for tables, and maybe sequences. There's no data to share in a function. In any case, references to remote objects such as Oracle can do seem like an entirely separate issue. I'd prefer to avoid the Oracle terminology, if only to avoid confusion with that feature. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
