> 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 this would be extensible in the way the current code is.
> 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.
>
>
<snip>
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.)
in this case you are absolutely wrong - this is far from reality.
assume somebody started off with a DB2 based application. the program
was good. then it was ported to oracle. meanwhile 300 features were
changed, adapted, replaced, 5 programmers died and 20 left the company.
finally some other things were changed -> the internal structures of
stored procedures ended up as "don't touch me".
"sed s/ /gi ..." will be the key to introducing a significant amount of
unpredictable problems - in business applications nobody will even
CONSIDER touching something like that. i am not saying that cleaning up
is a good thing - in some cases it is simply not doable because the guy
who wrote the code died 5 years ago (this is a real story by the way).
i have seen databases where we had to define DELETE rules DO INSTEAD
NOTHING because nobody knew where a bad delete actually came from - THIS
is the kind of problem we are talking about.
to me using an alternative name is definitely not something which is bad
at all.
the fact that oracle supports something is definitely not an argument.
however, oracle invented this feature for a situation like the one i
described above. the problem is: this is a quite common scenario.
assume we would fix:
- search_path issue which was brought up
- pg_dump
- the docs
would there be a serious chance to get that approved?
many thanks,
hans
--
Cybertec Geschwinde & Schönig GmbH
Schöngrabern 134; A-2020 Hollabrunn
Tel: +43/1/205 10 35 / 340
www.postgresql.at, www.cybertec.at
