On Dec 7, 2010, at 2:10 AM, Tom Lane wrote:
> 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.
Agreed. I was also thinking about using catalog-specific changes to add
synonyms for objects other than tables, views and sequences. It also possible
that there's no need in synonyms for tables, but synonyms for table columns,
or database roles would be useful. Hence, the question is not only 'do we want
synonyms', but also, if we do, then for which kinds of objects?
>
> 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.
Agreed as well.
--
Alexey Klyukin http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc
