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


From: Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>,"Jim C(dot) Nasby" <jnasby(at)pervasive(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:29:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Alvaro Herrera wrote:
> Jonah H. Harris wrote:
>>Now, one may argue that it's incorrect/bad application-design to not use
>>fully qualified names, however, there are cases (especially in VERY large
>>database applications) where you do not want to use fully qualified naming.
>>In PostgreSQL, the alternative to synonyms is to have a monstrous search
>>path $user, public, HR, AP, AR, GL, FA, COMMON...  Not that we have Oracle
>>Applications running on PostgreSQL, but 11i has something like 130+? schemas
>>which would be pretty nasty and semi-unprofessional as a search_path rather
>>than as something defined similar to synonyms.
> Well, if you don't want to have a monstrous search path with 130+
> schemas, then you'll have a monstrous amount of synonyms.  Given that
> schemas are a way to separate the object namespace, it seems more
> sensible to me to propagate the user of reasonable search paths than the
> use of hundreds (thousands?) of synonyms.

synonyms are easier to handle for an application - adding the search 
path to an existing application can be too intrusive and error prone.


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:35:10
Subject: Re: CREATE SYNONYM ...
Previous:From: Hans-Jürgen SchönigDate: 2006-03-08 07:26:46
Subject: Re: CREATE SYNONYM ...

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