Re: procpid?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jim Nasby <jim(at)nasby(dot)net>
Cc: Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: procpid?
Date: 2011-06-13 15:22:18
Message-ID: BANLkTimhYcoGURp9pAtjiYYZ67pQkzZQjg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 13, 2011 at 11:20 AM, Jim Nasby <jim(at)nasby(dot)net> wrote:
> On Jun 11, 2011, at 9:36 PM, Robert Haas wrote:
>>> This is at least a use-case for something^Wfeature like 'create
>>> synonym', allowing smooth end-user's application upgrade on schema
>>> update. I am not claiming that we need that, it just seems a good
>>> usecase for column alias/synonym.
>>
>> I had the same thought.  I'm not sure that this particular example
>> would be worthwhile even if we had a column synonym facility.  But at
>> least if we were bent on changing it we could do it without breaking
>> things.
>
> A synonym feature would definitely be useful for cases like this. We have a poorly named database at work; it's been that way for years and the only reason it's never been cleaned up is because it would require simultaneously changing config settings in dozens of places on hundreds of machines (many of which are user machines, which makes performing the change very difficult). As annoying as dealing with the oddball name is (there's a number of pieces of code that have to special case it), it would be even more painful to fix the problem. If we had database name synonyms we could create a synonym and migrate everything over time... and in the meantime, code could stop special-casing it.

That's probably the best explanation of why synonyms would be useful I
believe I've yet heard.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-06-13 15:29:08 Re: FOREIGN TABLE doc fix
Previous Message Robert Haas 2011-06-13 15:21:25 Re: FOREIGN TABLE doc fix