Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Tue, 7 Mar 2006, Jim C. Nasby wrote:
>> Wouldn't the cost only be incurred if you searched for something in
>> pg_class that wasn't there, and therefor had to fall back to pg_synonym?
> I think if synonyms were search path dependant that wouldn't be true since
> you'd need to know if there was a synonym that shadowed another item.
Right, and that's exactly why I complained. Even if pg_synonym is
empty, it takes nonzero effort to find that out.
One reason I like the alternative of putting synonym entries into the
regular catalogs is that it eliminates the need for extra searches:
you'd make exactly the same searches as you did before. Now, to the
extent that this requires making catalog entries longer, there'd be a
distributed overhead that might partially cancel that out --- but I
don't see any reason that the entries have to get longer for regular
tables. The link field could be a nullable field at the end, and
the flag that it's a synonym would just be another relkind value.
I don't think the case for pg_proc synonyms has been made adequately at
all, so I'd personally just blow off that part of the proposal. There's
no real cost to just making another copy of the proc.
(Actually, I don't think the case for table synonyms has been made
adequately either; "Oracle has it" is *not* enough reason to take on
another feature that we'll have to maintain forever, especially given
that we're being told that one of the major use-cases for synonyms
isn't going to be supported. AFAICS this patch does nothing you
couldn't do much better with a quick search-and-replace over your
application code. In short, I remain unsold.)
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
