Re: SYNONYMs revisited

From: Joshua Tolley <eggyknap(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SYNONYMs revisited
Date: 2009-03-04 20:38:14
Message-ID: 20090304203811.GN25872@eddie
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 04, 2009 at 03:15:23PM -0500, Tom Lane wrote:
> Joshua Tolley <eggyknap(at)gmail(dot)com> writes:
> > I didn't mean to suggest that SQL/MED on its own could be used to make
> > SYNONYMs, but rather that given SQL/MED, perhaps we could reconsider
> > some sort of CREATE SYNONYM functionality to go along with it. A major
> > argument against CREATE SYNONYM in the past was that we wouldn't be able
> > to create synonyms representing remote objects because we couldn't
> > access remote objects. With SQL/MED that's no longer the case, so
> > perhaps that argument no longer applies.
>
> Well, we're still a long way from having SQL/MED ;-). In particular,
> one of the elements of that spec is CREATE FOREIGN TABLE, which I think
> basically *is* a synonym for a table on a remote server.

I hadn't followed SQL/MED to really see where we were; I just know that
being able to create a synonym for a function, a table, a view, etc.
seems like it would be neat (though I can't admit to having a list of
use cases, or a good argument for any particular interpretation of its
correct behavior). Since one concern expressed was that people might
expect to be able to create synonyms of foreign objects, and dismayed to
find they couldn't, perhaps having SQL/MED (one day) would remove
concerns about building some form of CREATE SYNONYM.

- Josh

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2009-03-04 20:50:54 Re: Prepping to break every past release...
Previous Message Joshua D. Drake 2009-03-04 20:32:59 Prepping to break every past release...