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

Re: Another proposal for table synonyms

From: Csaba Nagy <ncslists(at)googlemail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Alexey Klyukin <alexk(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Another proposal for table synonyms
Date: 2010-12-01 10:08:32
Message-ID: 1291198112.30409.13.camel@pcd12478 (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Hi all,

On Tue, 2010-11-30 at 12:05 -0800, Josh Berkus wrote:
> Can you explain, for our benefit, the use case for this?  Specifically,
> what can be done with synonyms which can't be done with search_path and
> VIEWs?

I had a few cases where synonyms for user/data base names would have
helped me slightly (not something I couldn't work around).

The actual use case was when I wanted to change the name of a data base
and user names (just a configuration coherency thing) - using a synonym
I could have done it without downtime by creating the synonym first,
then reconfiguring each application machine individually (they are
redundant, and can be restarted transparently). Without the synonyms, I
had to wait for the next full downtime (which we do quite rarely) and
reconfigure the DB and all application boxes at the same time.

Ideally the user/DB name synonym would be like a hard link, equivalent
in all respects to the original name, so that you can delete the
original name and the synonym continues to work.

Likely the pg_hba.conf would need to still distinguish between the
DB/user names and their synonyms - not sure if that could be useful or
would be a PITA.

Of course this has nothing to do with the table synonyms - there I
didn't have yet any reason I would use one...


In response to

pgsql-hackers by date

Next:From: ghatpandeDate: 2010-12-01 10:19:32
Subject: Proposal: First step towards Intelligent,integrated database
Previous:From: Heikki LinnakangasDate: 2010-12-01 09:00:43
Subject: Re: GiST insert algorithm rewrite

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