Skip site navigation (1) Skip section navigation (2)


From: Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>,"Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>,"Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>,Michael Glaesemann <grzm(at)myrealbox(dot)com>,pgsql-patches(at)postgresql(dot)org, eg(at)cybertec(dot)at
Subject: Re: CREATE SYNONYM ...
Date: 2006-03-08 07:20:33
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
> 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.


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,


Cybertec Geschwinde & Schönig GmbH
Schöngrabern 134; A-2020 Hollabrunn
Tel: +43/1/205 10 35 / 340,

In response to

pgsql-patches by date

Next:From: Hans-Jürgen SchönigDate: 2006-03-08 07:26:46
Subject: Re: CREATE SYNONYM ...
Previous:From: Hans-Jürgen SchönigDate: 2006-03-08 07:06:50
Subject: Re: CREATE SYNONYM ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group