Re: CREATE SYNONYM ...

On Wed, 8 Mar 2006, Jonah H. Harris wrote:

> On 3/8/06, Stephan Szabo <sszabo@megazone.bigpanda.com> wrote:
> >
> > Yes, however there are two slightly separate discussions going on and I
> > think you're taking them as a single discussion.
>
>
> I agree that there are two discussions happening in this thread, but I don't
> think anyone has agreed at all that this patch as it is would be acceptable
> for various reasons.  There are a couple things that Hans and I will discuss
> about the patch assuming we decide this is a feature that would be nice for
> PostgreSQL.

What feature though?  Part of the definition of a feature like synonym has
to nail down things like how it interacts with search path. The message I
was responding to was talking about the patch and seeming to say that
there wasn't a cost for non-users because the search was done iff a
candidate object wasn't found. IMHO, this is a different feature than a
synonym feature for which each search path entry is checked so that
synonyms in earlier path entries shadow later concrete objects. We
probably don't want both features even if we want either, but they're
really different features.

> With synonyms, the search path for Joe would remain $user, public and one
> could easily do
> CREATE SYNONYM public.employee FOR hr.employee;
> CREATE SYNONYM public.commissions FOR crm.commissions;

I would say that that's a really bad choice, and Joe should have his
synonyms somewhere other than public so as not to pollute other people's
default search path with his particular needs that may not be the same as
someone else's.  What does Jane do now when she needs the opposite set and
why is Joe's choice more relevant than Jane's?

This is not a negative effect of synonyms, merely this use.

> I guess synonym searching could be done iff no object were found in the
> current search.  I don't know why I thought it would be just as costly
> (perhaps too much Sam Adams).  The worst-case scenario would be an
> additional search only if an object weren't found in a catalog search,
> basically this would be the cost of using synonyms and wouldn't affect
> performance for everyone else.  Oracle does have a small cost only when
> using synonyms as well.

Yeah, that just seems less consistent with the rest of the way schema
searches work right now for other objects.