Re: CREATE SYNONYM ... - Mailing list pgsql-patches
| From | Jonah H. Harris |
|---|---|
| Subject | Re: CREATE SYNONYM ... |
| Date | |
| Msg-id | 36e682920603081715j3a09e545v3f459fbb3e8ce2ed@mail.gmail.com Whole thread Raw |
| In response to | Re: CREATE SYNONYM ... (Stephan Szabo <sszabo@megazone.bigpanda.com>) |
| Responses |
Re: CREATE SYNONYM ...
|
| List | pgsql-patches |
On 3/8/06, Stephan Szabo <sszabo@megazone.bigpanda.com> wrote:
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.
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.
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
732.331.1324
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 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
732.331.1324
pgsql-patches by date: