Andy Colson <andy@squeakycode.net> 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
