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


From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: 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>,"Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>,Hans-J?rgen Sch?nig <postgres(at)cybertec(dot)at>,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 13:16:44
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
* Neil Conway (neilc(at)samurai(dot)com) wrote:
> BTW, AFAICS synonyms for tables and views can be approximated by views:
> you pay a small runtime hit to expand the view definition, but that's
> fairly cheap for a simple view. Synonyms for functions can be
> approximated by shell functions defined in SQL -- those can even be
> inlined, reducing the amount of overhead. It's not as easy to define
> synonyms for sequences, but that is hardly justification for the
> feature.

If all you were doing with the view was reading from it then sure...
Creating the rules for all the views you want to make them updatable
wouldn't be fun.  That's actually the one thing I like about synonyms
over create view a as select * from b.a;

We've got a number of synonyms in our Oracle databases (no
cross-database ones or anything like that...) and I'd like to get rid of
them but the folks using them aren't too keen on that for various
reasons...  It'd be nice to be able to support them in Postgres without
having to go through alot of work.  Tom's suggestion for just an
additional catalog entry for them would be exactly what I'd need and
seems pretty straight-forward and simple to me.

Just my 2c.



In response to


pgsql-patches by date

Next:From: Jonah H. HarrisDate: 2006-03-08 13:51:07
Subject: Re: CREATE SYNONYM ...
Previous:From: Hannu KrosingDate: 2006-03-08 12:53:44
Subject: Re: [PATCHES] Inherited Constraints

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