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


From: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
To: "Stephan Szabo" <sszabo(at)megazone(dot)bigpanda(dot)com>
Cc: Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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-09 01:15:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
On 3/8/06, Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> wrote:
> What feature though?  Part of the definition of a feature like synonym has
> to nail down things like how it interacts with search path

I've said how it interacts with the search path (with Oracle) several times
and illustrated it in the last one, let's not go through this again.

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.

Like I said in the email before this, there is a way to limit the cost of
synonyms for ONLY if a real object does not exist in the search path.
However, this would be odd behavior regarding namespace searching IMHO.  I
think the only *good* implementation is to follow the search path as it is
now and include synonyms in it... this would mean a cost for any query
whether or not a synonym were used or not.  The real question is how to
lessen the cost if we decide to implement the functionality.

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?

Joe and Jane could create synonyms locally in their own schemas, so this
isn't an issue at all.  The demonstration example was representative of many
ERP systems where a synonym is publicly shared by all modules and you
wouldn't have the "Jane" issue.

I'm nearly done fighting this... synonyms are useful functionality that many
people in this discussion have not used.  I've explained how it works in
Oracle and the reasoning behind it.  If we want to limit users to
search_path for the sake of not being Oracle, fine.

I have patches to work on and this seems to be going nowhere.  I'm open to
helping anyone implement similar functionality and/or discussion, but this
thread has too many sub-discussions to be useful.  For functionality
descriptions, see the Oracle docs.  I'm not averse to straying from Oracle's
way of doing it if it makes sense.

Jonah H. Harris, Database Internals Architect
EnterpriseDB Corporation

In response to


pgsql-patches by date

Next:From: Stephan SzaboDate: 2006-03-09 02:14:49
Subject: Re: CREATE SYNONYM ...
Previous:From: Stephan SzaboDate: 2006-03-09 00:32:14
Subject: Re: CREATE SYNONYM ...

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