Re: Another proposal for table synonyms - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Another proposal for table synonyms
Date
Msg-id 28420.1291136620@sss.pgh.pa.us
Whole thread Raw
In response to Re: Another proposal for table synonyms  (Alexey Klyukin <alexk@commandprompt.com>)
List pgsql-hackers
Alexey Klyukin <alexk@commandprompt.com> writes:
> On Nov 30, 2010, at 6:28 PM, Tom Lane wrote:
>> This is not going to work, at least not without making every type of
>> lookup consult pg_synonym too, which I think can be considered DOA
>> because of its performance impact on people who aren't even using the
>> feature.

> For those not using synonyms it would result in an extra syscache lookup for
> each schema from the search_path that doesn't contain the table with the
> specified name. If the table is specified with A FQN or contained in the first
> schema from the search_path no extra lookup would occur. Is it considered a
> big impact?

Yes.  It'll be slow and it will render code that's already unreasonably
complicated into an unreadable morass.  We are not going there.

(Just to be clear, it's not the table search case I'm worried about;
it's operator/function lookup that I think this would be completely
unacceptable for.  And if you're only going to support table/view
synonyms then you might as well put them in pg_class.)

> I think that would almost guarantee that synonyms for other kinds of objects
> (i.e. databases, such kind of synonyms were requested in the past) would never
> be added.

That's fine with me.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: crash-safe visibility map, take three
Next
From: Tom Lane
Date:
Subject: Re: crash-safe visibility map, take three