What I don't really understand is what part of this cannot be achieved
by changing the search_path. The only case I can think of is when you
have tables A and B in schemas R and S, but you want to use R.A and S.B.
So there's no way to change search_path for this. But is this really
the intended use case?
yes, this is a very practical case ...
I wonder whether synonyms were introduced in Oracle because of that idea
of theirs that each user has its own schema, and can access that schema
only; so to use a table in another schema you need to create a synonym.
We don't have that limitation so we don't need that usage either.
i am sure this was a reason but not the only one.
some other reason could be (again, bad but widespread): somebody defined
a bad data structure where everything is in separate tables (tom's cars
are in table A, bruce's cars are in table B). somebody finally finds out
that this was a bad idea (3mio lines of code were built on top of this
crap) and that those tables should be combined. a synonym will help.
just think of broken applications such as SAP - everything is in a
separate table (maybe they have 100000000000000 which only stored
desciptions), if you want to cleanup a synonym is less error prone than
'sed -e ...'.
if synonyms are a broken concept then the same would apply for softlinks
and hardlinks supported by filesystem - still people like soft/hardlinks
and they are widely adopted because they are useful. of course, you can
live without file systems links if you can afford changing the path
after every line of shell code.
best regards,
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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
