Re: Another proposal for table synonyms

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alexey Klyukin <alexk(at)commandprompt(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Another proposal for table synonyms
Date: 2010-11-30 17:03:40
Message-ID: 28420.1291136620@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alexey Klyukin <alexk(at)commandprompt(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-11-30 17:10:49 Re: crash-safe visibility map, take three
Previous Message Robert Haas 2010-11-30 17:01:56 Re: crash-safe visibility map, take three