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

Re: CREATE SYNONYM ...

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>
Cc: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>,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-08 07:44:05
Message-ID: 20060307233657.H64314@megazone.bigpanda.com (view raw or flat)
Thread:
Lists: pgsql-patches
On Wed, 8 Mar 2006, [ISO-8859-1] Hans-Jürgen Schönig wrote:

> Stephan Szabo wrote:
> > On Tue, 7 Mar 2006, Jonah H. Harris wrote:
> >
> >
> >>On 3/7/06, Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> wrote:
> >>
> >>>I'd personally be more interested in what the impact is on people not
> >>>using synonyms. How free is any search for synonyms if you aren't using
> >>>the feature?
> >>
> >>
> >>Unless synonym enablement were a configurable parameter (which wouldn't
> >>really make sense), the cost would be the same whether they're used or not
> >>during searching.
> >
> >
> > Right, but the response was that "using" synonyms incurred a cost and this
> > should be documented.  However, if there's a cost to people not using
> > synonyms there's a higher barrier to entry for the feature.
> >
>
>
> the costs will only be added if the "real table" is not found.
> therefore there is no impact on "normal" users.

Doesn't that pretty much go against the (I thought) outstanding behavioral
question of whether the synonyms are scoped and obey search path?  If they
do, I don't see how the above rule can hold since finding the "real table"
is insufficient to know if there's an earlier synonym.

In response to

Responses

pgsql-patches by date

Next:From: Neil ConwayDate: 2006-03-08 08:02:02
Subject: Re: CREATE SYNONYM ...
Previous:From: Hans-Jürgen SchönigDate: 2006-03-08 07:43:49
Subject: Re: CREATE SYNONYM ...

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