Skip site navigation (1) Skip section navigation (2)


From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>,"Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>,"Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>,Hans-J?rgen Sch?nig <postgres(at)cybertec(dot)at>,Michael Glaesemann <grzm(at)myrealbox(dot)com>,pgsql-patches(at)postgresql(dot)org, eg(at)cybertec(dot)at
Subject: Re: CREATE SYNONYM ...
Date: 2006-03-07 22:28:40
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Tom Lane wrote:

> (Actually, I don't think the case for table synonyms has been made
> adequately either; "Oracle has it" is *not* enough reason to take on
> another feature that we'll have to maintain forever, especially given
> that we're being told that one of the major use-cases for synonyms
> isn't going to be supported.  AFAICS this patch does nothing you
> couldn't do much better with a quick search-and-replace over your
> application code.  In short, I remain unsold.)

What I don't really understand is what part of this cannot be achieved
by changing the search_path.  The only case I can think of is when you
have tables A and B in schemas R and S, but you want to use R.A and S.B.
So there's no way to change search_path for this.  But is this really
the intended use case?

I wonder whether synonyms were introduced in Oracle because of that idea
of theirs that each user has its own schema, and can access that schema
only; so to use a table in another schema you need to create a synonym.
We don't have that limitation so we don't need that usage either.

Alvaro Herrera                      
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to


pgsql-patches by date

Next:From: Neil ConwayDate: 2006-03-07 22:54:00
Subject: variance aggregates per SQL:2003
Previous:From: Tom LaneDate: 2006-03-07 22:14:48
Subject: Re: CREATE SYNONYM ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group