Search Postgresql Archives

Re: Do we want SYNONYMS?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





2010/12/7 Andy Colson <andy@xxxxxxxxxxxxxxx>
On 12/7/2010 8:12 AM, Daniel Verite wrote:
   ÂVick Khera wrote:

On Mon, Dec 6, 2010 at 2:31 PM, Joshua D. Drake<jd@xxxxxxxxxxxxxxxxx>
wrote:
Command Prompt is currently considering writing a patch to provide
synonyms to PostgreSQL. Is this something the community is interested
in? Do we have use cases for it? MSSQL, DB2 and Oracle support them.


I must be missing something, but really, what's the point of synonyms?
ÂWhat's the real-world use case for them?

It's about decoupling the name from the actual object, much like what soft
links are for file systems.
It's convenient when you need to change the underlying object without
touching the application code.

Best regards,

So, you could rename a table without having to change the code? ÂBut you cant rename a column, or drop one, and thats a much more common thing I'd bet. ÂAnd eventually you would change the code, right? ÂIsn't it much better to keep everyone on the same page? ÂIf you have 10 program using 10 different names for the same table... how can that possibly be useful? ÂJust sounds confusing and troublesome.

I can see a situation for live/hot upgrades. ÂHaving old code and new code run at the same time. ÂBut eventually the old code would go away, and I think the same thing could be handled with views. Â(perhaps updateable view's would be required... but still)

I dont see a situation where an alias gives me something updateable views dont. ÂI'd vote we spend time on updateable views instead.

And the types:

table: maybe useful for live upgrade, but views, transactons and stored procs do the same thing.

views: just create the new view. ÂHave both. Âwhen the old code goes away, drop the old view. ÂNo need for an alias.

sequence: Âwhy bother? ÂOther than renaming during live upgrade, why would you need an alias?

index: Âagain, why bother... code really should not ever be dependent on an indexes name, correct? ÂAnd transactions take care of live updates.

So for the two use cases I've seen (live update, directing data flow (which is kinda like a live update)) we already have tools that do it: transactional ddl, views, schemas, stored procs, etc. ÂUpdateable views might be the only thing missing.

Also: ÂI wonder if it might be a bad idea. ÂThe people coming from oracle will see that PG supports synonyms, and they'll be all happy, but when they get into the guts of their translate they find PG's synonyms are different (and not compatible), and they have to throw it out and use schemas instead.

On the other hand, now that I think about it, if its really easy, it might help a few people out, then why not. ÂOn the other other hand, if its not so easy, I think the time would be better spent on updatable views.

So here is my new vote:
IF its easy and wont slow anything down: +1
IF its hard: -1 (and spend the time on more important things)
Totally agreed.

-Andy


--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general



--
// Dmitriy.



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux