From: | Hans-Jürgen Schönig <postgres(at)cybertec(dot)at> |
---|---|
To: | "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal for SYNONYMS |
Date: | 2006-03-09 17:55:22 |
Message-ID: | 44106C0A.3040105@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jonah H. Harris wrote:
>
>
> This email is a preliminary design for the implementation of synonyms in
> PostgreSQL. Comments and suggestions are welcomed.
>
> BACKGROUND
>
> Synonyms are database objects which can be used in place of their
> referenced object in SELECT, INSERT, UPDATE, and DELETE SQL statements.
>
> There are two reasons to use synonyms which include:
>
> - Abstraction from changes made to the name or location of database objects
> - Alternative naming for another database object
>
> Similarly, RDBMS support for synonyms exists in Oracle, SQL Server, DB2,
> SAP DB/MAX DB, and Mimer.
>
> PROPOSED SQL ADDITIONS
>
> CREATE SYNONYM qualified_name FOR qualified_name
> DROP SYNONYM qualified_name
>
> In addition, SYNONYMS do participate in ACLs and support GRANT/REVOKE
> for table privileges. DROP TABLE and TRUNCATE cannot be used with synonyms.
>
> DESCRIPTION
>
> - A synonym can be created for a table, view, or synonym.
> - Synonyms can reference objects in any schema
>
> RESTRICTIONS
>
> - A synonym may only be created if the creator has some access privilege
> on the referenced object.
> - A synonym can only be created for an existing table, view or synonym.
> - A synonym name cannot be the same as the name of any other table, view
> or synonym which exists in the schema where the synonym is to be created.
>
> PROPOSED IMPLEMENTATION
>
> - Introduce a new relkind for synonyms
> - Synonyms only act as pointers to a real object by oid
> - Permission on a synonym does not override the permission on the
> referenced object
> - Referenced objects becomes dependencies of the synonyms that reference
> them
> - Synonyms follow PostgreSQL's current search_path behavior
>
> RUNTIME COST
>
> - Dependent on database user/administrator
> - In catalog searches which do not reference a synonym, the only cost
> incurred is that of searching the additional number of synonym objects
> in the catalog
> - In catalog searches which use a synonym, an additional cost is
> incurred to reference the real object
> - If no synonyms are created, no additional costs are incurred
>
hi jonah ...
the main problem i can see here is that it is strictly limited to
objects stored in pg_class.
however, support for stored procedures would be cool as well. what do
you suggest for those?
best regards,
hans
--
Cybertec Geschwinde & Schönig GmbH
Schöngrabern 134; A-2020 Hollabrunn
Tel: +43/1/205 10 35 / 340
www.postgresql.at, www.cybertec.at
From | Date | Subject | |
---|---|---|---|
Next Message | Volkan YAZICI | 2006-03-09 18:02:05 | Re: 8.2 hold queue [MB Chars' Case Conversion] |
Previous Message | Tom Lane | 2006-03-09 17:44:40 | Re: Merge algorithms for large numbers of "tapes" |