Re: Oracle => Postgresql

Bonjour,
Je suis un Oraclien qui doit migrer à Postgresql !
J'aimerais bien quelques infos sur la transcription de certains concepts Oracle en Postgresql
En effet sous Oracle
On a les possibilités suivantes
Database => Schéma => (Fonction + Procédure)
Database => Schéma => Package => (Fonction + Procédure)
Je fais une utilisation intensive des packages car ils permettent de
Factoriser le code
Gérer les droits d'accès
Limiter la visibilité des fonctions et procédures
Par ex schéma employee avec packages drh (pour l'administration), emp (pour la consultation par les employés)

J'ai parcouru la doc de la 8.2 mais je n'ai rien trouvé à ce sujet !
Dans les Todo j'ai vu que Pavel devait offrir cette fonctionnalité ... un jour !

Quelqu'un peut-il me donner davantage d'informations et surtout je suis curieux de savoir comment les utilisateurs de Postgresql gèrent cette problématique
D'avance merci
Bir
_________________________________________________________
Birahim FALL
Systems & Network Manager (IT & Methods Programme of Logistics Directorate)
Universal Postal Union,
PO Box, CH-3000 Bern 15 (Switzerland)
Phone +41 313.503.111
Phone +41 313.503.372 (Direct)
Fax +41 313.503.110
Email mailto:birahim(dot)fall(at)upu(dot)int

UPU.PostgreSQL a écrit :
> Bonjour,
> Je suis un Oraclien qui doit migrer à Postgresql !
> J'aimerais bien quelques infos sur la transcription de certains concepts Oracle en Postgresql
> En effet sous Oracle
> On a les possibilités suivantes
> Database => Schéma => (Fonction + Procédure)
> Database => Schéma => Package => (Fonction + Procédure)
> Je fais une utilisation intensive des packages car ils permettent de
> Factoriser le code
> Gérer les droits d'accès
> Limiter la visibilité des fonctions et procédures
> Par ex schéma employee avec packages drh (pour l'administration), emp (pour la consultation par les employés)
>
> J'ai parcouru la doc de la 8.2 mais je n'ai rien trouvé à ce sujet !
> Dans les Todo j'ai vu que Pavel devait offrir cette fonctionnalité ... un jour !
>
> Quelqu'un peut-il me donner davantage d'informations et surtout je suis curieux de savoir comment les utilisateurs de Postgresql gèrent cette problématique
>
Bonjour,

je suppose que ce lien vous donnerales détails attendus :
http://docs.postgresqlfr.org/8.3/user-manag.html

En gros, vous pouvez avoir des user ou des groupes au sein de 'role', il
suffit de grant/revoke le schema avec le/les roles (qui peuvent etre des
groupes d'utilisateurs).

> D'avance merci
> Bir
> _________________________________________________________
> Birahim FALL
> Systems & Network Manager (IT & Methods Programme of Logistics Directorate)
> Universal Postal Union,
> PO Box, CH-3000 Bern 15 (Switzerland)
> Phone +41 313.503.111
> Phone +41 313.503.372 (Direct)
> Fax +41 313.503.110
> Email mailto:birahim(dot)fall(at)upu(dot)int
>
>
>
>

--
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org

Oracle => Postgresql ----- Original Message -----
From: UPU.PostgreSQL
To: pgsql-fr-generale(at)postgresql(dot)org
Sent: Monday, January 07, 2008 8:56 AM
Subject: [pgsql-fr-generale] Oracle => Postgresql

Bonjour,

Je suis un Oraclien qui doit migrer à Postgresql !

J'aimerais bien quelques infos sur la transcription de certains concepts Oracle en Postgresql

En effet sous Oracle

On a les possibilités suivantes

Database => Schéma => (Fonction + Procédure)

Database => Schéma => Package => (Fonction + Procédure)

Je fais une utilisation intensive des packages car ils permettent de

Factoriser le code

Gérer les droits d'accès

Limiter la visibilité des fonctions et procédures

Par ex schéma employee avec packages drh (pour l'administration), emp (pour la consultation par les employés)

J'ai parcouru la doc de la 8.2 mais je n'ai rien trouvé à ce sujet !

Dans les Todo j'ai vu que Pavel devait offrir cette fonctionnalité . un jour !

Quelqu'un peut-il me donner davantage d'informations et surtout je suis curieux de savoir comment les utilisateurs de Postgresql gèrent cette problématique

D'avance merci

Bir

_________________________________________________________

Birahim FALL

Systems & Network Manager (IT & Methods Programme of Logistics Directorate)

Universal Postal Union,

PO Box, CH-3000 Bern 15 (Switzerland)

Phone +41 313.503.111

Phone +41 313.503.372 (Direct)

Fax +41 313.503.110

Email mailto:birahim(dot)fall(at)upu(dot)int

Il n'y a pas dans Postgresql l'équivalent des packages Oracle.

S'il ne s'agit que d'un problème de nommage, on peut remplacer

NOM_PACKAGE.NOM_PROC par NOM_SCHEMA.NOM_PROC

mais on ne peut avoir comme en Oracle

NOM_SCHEMA.NOM_PACKAGE.NOM_PROC

En revanche, on peut "singer" le nommage à trois niveaux car les noms d'objets Postgresql peuvent comporter (de mémoire) 63 caractères alors qu'ils sont limités à 30 caractères en Oracle.

Les GRANT EXECUTE se feront au niveau NOM_SCHEMA.NOM_PROC en Postgresql.

A. DUPUIS

A. DUPUIS a écrit :
(...)
> Il n'y a pas dans Postgresql l'équivalent des packages Oracle.
>
> S'il ne s'agit que d'un problème de nommage, on peut remplacer
>
> NOM_PACKAGE.NOM_PROC par NOM_SCHEMA.NOM_PROC
>
> mais on ne peut avoir comme en Oracle
>
> NOM_SCHEMA.NOM_PACKAGE.NOM_PROC

Mon souvenir sur l'articulation ("standard") SQL d'un nommage était le
suivant : NOM_BASE.NOM_SCHEMA.NON_OBJET. Manifestement j'ai loupé un
chapitre et n'ai même jamais utilisé la notion de package sous Oracle
(ma formation de DBA remonte à Oracle 7, ça date). En revanche ce qui
n'est pas encore possible avec Pg c'est l'utilisation de NOM_BASE qui
permet sous oracle de faire une sélection dans une autre base,
différente de la courante. J'avoue que sur le papier c'est très
séduisant. En pratique cela m'a manqué quelquefois sous Pg. Mais ça
viendra, le 2-phases commit est un préalable nécessaire qui maintenant
est implémenté dans Pg.

(...)

Cordialement,
Stéphane BUNEL.

André,

Merci pour ces explications !

Je dois donc me faire à ce changement de philosophie !

Mais c'est quand même bien pratique les packages oracle car on peut y regrouper des fonctions, procédures et définitions spécifiques à un traitement particulier puis faire le grant execute au niveau du package !

Mais comment font les programmeurs pour cela ?

1) Un schema pour chaque package,

ou alors

2) tout dans le même schéma avec la gestion à la main de grant execute sur schema.package1.fonction*, ..., schema.packageN.fonction*, etc ?

Question subsidiaire : Quid de ce que j'ai lu dans la Todo liste à propos de cette fonctionnalité ? Est-ce une problématique ou un demande qui revient souvent ou dois-je me faire une raison ?

Merci encore.

Bir

________________________________

From: A. DUPUIS [mailto:andre(dot)dupuis(at)u-bourgogne(dot)fr]
Sent: lundi, 7. janvier 2008 16:17
To: UPU.PostgreSQL; pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: [pgsql-fr-generale] Oracle => Postgresql

----- Original Message -----

From: UPU.PostgreSQL <mailto:UPU(dot)PostgreSQL(at)upu(dot)int>

To: pgsql-fr-generale(at)postgresql(dot)org

Sent: Monday, January 07, 2008 8:56 AM

Subject: [pgsql-fr-generale] Oracle => Postgresql

Bonjour,

Je suis un Oraclien qui doit migrer à Postgresql !

J'aimerais bien quelques infos sur la transcription de certains concepts Oracle en Postgresql

En effet sous Oracle

On a les possibilités suivantes

Database => Schéma => (Fonction + Procédure)

Database => Schéma => Package => (Fonction + Procédure)

Je fais une utilisation intensive des packages car ils permettent de

Factoriser le code

Gérer les droits d'accès

Limiter la visibilité des fonctions et procédures

Par ex schéma employee avec packages drh (pour l'administration), emp (pour la consultation par les employés)

J'ai parcouru la doc de la 8.2 mais je n'ai rien trouvé à ce sujet !

Dans les Todo j'ai vu que Pavel devait offrir cette fonctionnalité ... un jour !

Quelqu'un peut-il me donner davantage d'informations et surtout je suis curieux de savoir comment les utilisateurs de Postgresql gèrent cette problématique

D'avance merci

Bir

_________________________________________________________

Birahim FALL

Systems & Network Manager (IT & Methods Programme of Logistics Directorate)

Universal Postal Union,

PO Box, CH-3000 Bern 15 (Switzerland)

Phone +41 313.503.111

Phone +41 313.503.372 (Direct)

Fax +41 313.503.110

Email mailto:birahim(dot)fall(at)upu(dot)int <mailto:birahim(dot)fall(at)upu(dot)int>

Il n'y a pas dans Postgresql l'équivalent des packages Oracle.

S'il ne s'agit que d'un problème de nommage, on peut remplacer

NOM_PACKAGE.NOM_PROC par NOM_SCHEMA.NOM_PROC

mais on ne peut avoir comme en Oracle

NOM_SCHEMA.NOM_PACKAGE.NOM_PROC

En revanche, on peut "singer" le nommage à trois niveaux car les noms d'objets Postgresql peuvent comporter (de mémoire) 63 caractères alors qu'ils sont limités à 30 caractères en Oracle.

Les GRANT EXECUTE se feront au niveau NOM_SCHEMA.NOM_PROC en Postgresql.

A. DUPUIS

Stéphane BUNEL wrote:

> En revanche ce qui n'est pas encore possible avec Pg c'est
l'utilisation de NOM_BASE
> qui permet sous oracle de faire une sélection dans une autre base,
différente de la courante

Ah non car dans une instance Oracle il n'y a qu'une seule base.
NOM_BASE.NOM_TABLE c'est plutôt avec MySQL que c'est pratiqué.

--
Daniel
PostgreSQL-powered mail user agent and storage:
http://www.manitou-mail.org

Bonjour la liste,

> Je dois donc me faire à ce changement de philosophie !

Bof, ce n'est pas si gênant que cela, si ?

Je comprends, par contre, que ça ne soit pas toujours aisé à migrer
d'Oracle à PostgreSQL quand il y a des Packages de partout :/

> Mais c’est quand même bien pratique les packages oracle car on peut y
> regrouper des fonctions, procédures et définitions spécifiques à un
> traitement particulier puis faire le grant execute au niveau du package!

Effectivement, c'est vrai. Voici une page qui donne une définition plus
étoffée du Package Oracle:

http://download-uk.oracle.com/docs/cd/B13789_01/appdev.101/b10802/intro.htm#1021869

«Package Overview

A package is an encapsulated collection of related program objects
stored together in the database. Program objects are procedures,
functions, variables, constants, cursors, and exceptions.

Packages have many advantages over standalone procedures and functions.
For example, they:

1* Let you organize your application development more efficiently.

2* Let you grant privileges more efficiently.

3* Let you modify package objects without recompiling dependent
schema objects.

4* Enable Oracle to read multiple package objects into memory at once.

5* Let you overload procedures or functions. Overloading means
creating multiple procedures with the same name in the same package,
each taking arguments of different number or datatype.

6* Can contain global variables and cursors that are available to all
procedures and functions in the package.»
»

Mes commentaires:

1/ "more efficiently": "plus efficacement":

En fait, ce qu'il faut bien comprendre, c'est que sous Oracle, un schéma
c'est surtout un user de base de données. D'ailleurs, il porte
généralement le nom de l'user.

Sous PostgreSQL, c'est une entité logique qui sert à regrouper des
objets de base de données (tables, index, fonction, triggers, etc).
C'est pareil sous Oracle.

Pour avoir une entité logique sous Oracle, *recompilable*, on a créé le
PACKAGE. Comme ça n'était pas assez simple, on l'a scindé en deux
parties: le PACKAGE (header) et le PACKAGE BODY. Ceux qui connaissent le
C peuvent faire un parallèle heureux avec le .h et le .c d'un code
source. C'est pareil.

Donc 'plus efficacement': c'est une façon de dire: comme sous Oracle on
pouvait pas faire autrement que comme ça, on va dire à nos utilisateurs
que c'est efficace de faire comme ça...

Maintenant, c'est vrai que c'est une façon de regrouper les fonctions et
procédures.

Mais on aurait pu faire aussi des schémas distincts sous Oracle, comme
on le fait sous PostgreSQL.

2/ Affecter des privilèges de manière plus efficace

C'est vrai, sous Oracle. Sous PostgreSQL, c'est au niveau du schéma
qu'on le fera.

À noter que les privilèges Oracle sont bien plus subtils que ceux sous
PostgreSQL... Reste à savoir si on les utilise vraiment sous Oracle.

3/ Alors pour ce qui est de la compilation, effectivement, c'est
pratique sous Oracle. Sous PostgreSQL, on s'en moque.

4/ On s'en moque sous PostgreSQL, qui contrairement à Oracle, ne
mobilise la mémoire que s'il s'en sert. Et *sait la rendre* ensuite :-))

5/ La surcharge est tout à fait possible sous PostgreSQL. C'est à dire,
pour un même nom de fonction, son code peut changer, en fonction du
nombre ou de la nature des arguments.

6/ Variables globales et curseurs locaux au Package

Ça c'est un plus qu'à Oracle sur PostgreSQL. Par exemple, le curseur
"clients" peut être partagé par toutes les fonctions du package
"marketting". Sous PostgreSQL, il faudra copier la définition du curseur
dans toutes les fonctions.

Au final, pour moi, les Packages, sous PostgreSQL, on peut s'en passer.

C'est d'ailleurs probablement pour cela qu'ils n'existent pas sous
PostgreSQL...

> Mais comment font les programmeurs pour cela ?
>
> 1) Un schema pour chaque package,

C'est ce qu'on fait généralement quand on veut faire propre. En gros, un
schéma est un domaine, qui regroupe des entités cohérentes entre elles.

> ou alors
>
> 2) tout dans le même schéma avec la gestion à la main de grant
> execute sur schema.package1.fonction*, …, schema.packageN.fonction*, etc ?

Rien ne vous empêche de faire sale, en effet :-))

Certains s'amusent à préfixer les objets, pour faire un simulacre de
Package. En pratique, ça n'a aucun autre intérêt que de voir les
fonctions alignées les unes sous les autres dans pgAdmin :)

note: schema.package.fonction: ça n'existe pas sous PostgreSQL.

> Question subsidiaire : Quid de ce que j’ai lu dans la Todo liste à
> propos de cette fonctionnalité ? Est-ce une problématique ou un demande
> qui revient souvent ou dois-je me faire une raison ?

Tout d'abord, vous recconaîtrez que cette *feature* est classée dans les
"Exotic Features".. Pour moi ça veut tout dire...

Et surtout, comprenez bien comment Pavel formule la demande:
«A package would be a schema with session-local variables,
public/private functions, and initialization functions»...

« Un package serait un schéma qui... »

Conclusion: la demande est exotique, un schéma, ça existe déjà sous
PostgreSQL.

En espérant avoir contribué à éclairer votre lanterne, je vous souhaite
une agréable soirée,

--
Jean-Paul Argudo
www.PostgreSQLFr.org

----- Original Message -----
From: "Stéphane BUNEL" <stephane+pgfr(at)bpf(dot)st>
To: "A. DUPUIS" <andre(dot)dupuis(at)u-bourgogne(dot)fr>
Cc: "UPU.PostgreSQL" <UPU(dot)PostgreSQL(at)upu(dot)int>;
<pgsql-fr-generale(at)postgresql(dot)org>
Sent: Monday, January 07, 2008 4:56 PM
Subject: Re: [pgsql-fr-generale] Oracle => Postgresql

> A. DUPUIS a écrit :
> (...)
>> Il n'y a pas dans Postgresql l'équivalent des packages Oracle.
>>
>> S'il ne s'agit que d'un problème de nommage, on peut remplacer
>> NOM_PACKAGE.NOM_PROC par NOM_SCHEMA.NOM_PROC
>> mais on ne peut avoir comme en Oracle
>> NOM_SCHEMA.NOM_PACKAGE.NOM_PROC
>
> Mon souvenir sur l'articulation ("standard") SQL d'un nommage était le
> suivant : NOM_BASE.NOM_SCHEMA.NON_OBJET. Manifestement j'ai loupé un
> chapitre et n'ai même jamais utilisé la notion de package sous Oracle (ma
> formation de DBA remonte à Oracle 7, ça date). En revanche ce qui n'est
> pas encore possible avec Pg c'est l'utilisation de NOM_BASE qui permet
> sous oracle de faire une sélection dans une autre base, différente de la
> courante. J'avoue que sur le papier c'est très séduisant. En pratique cela
> m'a manqué quelquefois sous Pg. Mais ça viendra, le 2-phases commit est un
> préalable nécessaire qui maintenant est implémenté dans Pg.
>
> (...)
>
> Cordialement,
> Stéphane BUNEL.
>
>

A ma connaissance, la notation NOM_BASE.NOM_SCHEMA.NOM_OBJET n'est pas
disponible sous Oracle.

On peut cependant invoquer certains objets stockés (Tables, vues,
procédures stockées) dans une autre base Oracle à travers un lien base de
données (Database link).

Un lien base de données peut se voir comme une chaîne de connexion du
type:

AdresseMachineHoteDistante:PortEcoute:NomInstanceBD

Dans ce cas, la notation est la suivante:

NOM_SCHEMA . NOM_OBJET @ NOM_LIEN_BD

Cordialement
A. DUPUIS

Oracle => Postgresql Je ne sais quels sont les contours exact de votre problématique, mais vous pouvez éventuellement jeter un oil sur EntrepriseDB.

C'est un SGBD construit sur Postgesql et dont l'ambition est d'être largement "Oracle like".

C'est notamment le cas sur les vues du dictionnaire de données et sur l'ajout du langage PL/SQL.

A voir jusqu'à quel point ?

Cordialement.
A. DUPUIS

----- Original Message -----
From: UPU.PostgreSQL
To: A. DUPUIS ; pgsql-fr-generale(at)postgresql(dot)org
Sent: Monday, January 07, 2008 5:03 PM
Subject: Re: [pgsql-fr-generale] Oracle => Postgresql

André,

Merci pour ces explications !

Je dois donc me faire à ce changement de philosophie !

Mais c'est quand même bien pratique les packages oracle car on peut y regrouper des fonctions, procédures et définitions spécifiques à un traitement particulier puis faire le grant execute au niveau du package !

Mais comment font les programmeurs pour cela ?

1) Un schema pour chaque package,

ou alors

2) tout dans le même schéma avec la gestion à la main de grant execute sur schema.package1.fonction*, ., schema.packageN.fonction*, etc ?

Question subsidiaire : Quid de ce que j'ai lu dans la Todo liste à propos de cette fonctionnalité ? Est-ce une problématique ou un demande qui revient souvent ou dois-je me faire une raison ?

Merci encore.

Bir

------------------------------------------------------------------------------

From: A. DUPUIS [mailto:andre(dot)dupuis(at)u-bourgogne(dot)fr]
Sent: lundi, 7. janvier 2008 16:17
To: UPU.PostgreSQL; pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: [pgsql-fr-generale] Oracle => Postgresql

----- Original Message -----

From: UPU.PostgreSQL

To: pgsql-fr-generale(at)postgresql(dot)org

Sent: Monday, January 07, 2008 8:56 AM

Subject: [pgsql-fr-generale] Oracle => Postgresql

Bonjour,

Je suis un Oraclien qui doit migrer à Postgresql !

J'aimerais bien quelques infos sur la transcription de certains concepts Oracle en Postgresql

En effet sous Oracle

On a les possibilités suivantes

Database => Schéma => (Fonction + Procédure)

Database => Schéma => Package => (Fonction + Procédure)

Je fais une utilisation intensive des packages car ils permettent de

Factoriser le code

Gérer les droits d'accès

Limiter la visibilité des fonctions et procédures

Par ex schéma employee avec packages drh (pour l'administration), emp (pour la consultation par les employés)

J'ai parcouru la doc de la 8.2 mais je n'ai rien trouvé à ce sujet !

Dans les Todo j'ai vu que Pavel devait offrir cette fonctionnalité . un jour !

Quelqu'un peut-il me donner davantage d'informations et surtout je suis curieux de savoir comment les utilisateurs de Postgresql gèrent cette problématique

D'avance merci

Bir

_________________________________________________________

Birahim FALL

Systems & Network Manager (IT & Methods Programme of Logistics Directorate)

Universal Postal Union,

PO Box, CH-3000 Bern 15 (Switzerland)

Phone +41 313.503.111

Phone +41 313.503.372 (Direct)

Fax +41 313.503.110

Email mailto:birahim(dot)fall(at)upu(dot)int

Il n'y a pas dans Postgresql l'équivalent des packages Oracle.

S'il ne s'agit que d'un problème de nommage, on peut remplacer

NOM_PACKAGE.NOM_PROC par NOM_SCHEMA.NOM_PROC

mais on ne peut avoir comme en Oracle

NOM_SCHEMA.NOM_PACKAGE.NOM_PROC

En revanche, on peut "singer" le nommage à trois niveaux car les noms d'objets Postgresql peuvent comporter (de mémoire) 63 caractères alors qu'ils sont limités à 30 caractères en Oracle.

Les GRANT EXECUTE se feront au niveau NOM_SCHEMA.NOM_PROC en Postgresql.

A. DUPUIS

André Dupuis wrote:
> Je ne sais quels sont les contours exact de votre problématique,
> mais vous pouvez éventuellement jeter un œil sur EntrepriseDB.
>
> C'est un SGBD construit sur Postgesql et dont l'ambition est d'être
> largement "Oracle like".
>
> C'est notamment le cas sur les vues du dictionnaire de données et
> sur l'ajout du langage PL/SQL.
>
> A voir jusqu'à quel point ?
>

Les packages sont gérés sous EDB. Pour le reste, comme je ne connais pas
Oracle...

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

Bonjour,
Cette réponse détaillée à l'avantage d'être limpide!
Par cette question je voulais surtout avoir une direction à suivre pour ne pas bidouiller, bref faire un truc propre!
Je n'ai plus qu'à m'y mettre ...
Merci beaucoup, et certainement à bientôt !
Bir

-----Original Message-----
From: Jean-Paul Argudo [mailto:jean-paul(at)argudo(dot)org]
Sent: lundi, 7. janvier 2008 18:33
To: UPU.PostgreSQL
Cc: A. DUPUIS; pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: [pgsql-fr-generale] Oracle => Postgresql

Bonjour la liste,

> Je dois donc me faire à ce changement de philosophie !

Bof, ce n'est pas si gênant que cela, si ?

Je comprends, par contre, que ça ne soit pas toujours aisé à migrer
d'Oracle à PostgreSQL quand il y a des Packages de partout :/

> Mais c'est quand même bien pratique les packages oracle car on peut y
> regrouper des fonctions, procédures et définitions spécifiques à un
> traitement particulier puis faire le grant execute au niveau du package!

Effectivement, c'est vrai. Voici une page qui donne une définition plus
étoffée du Package Oracle:

http://download-uk.oracle.com/docs/cd/B13789_01/appdev.101/b10802/intro.htm#1021869

«Package Overview

A package is an encapsulated collection of related program objects
stored together in the database. Program objects are procedures,
functions, variables, constants, cursors, and exceptions.

Packages have many advantages over standalone procedures and functions.
For example, they:

1* Let you organize your application development more efficiently.

2* Let you grant privileges more efficiently.

3* Let you modify package objects without recompiling dependent
schema objects.

4* Enable Oracle to read multiple package objects into memory at once.

5* Let you overload procedures or functions. Overloading means
creating multiple procedures with the same name in the same package,
each taking arguments of different number or datatype.

6* Can contain global variables and cursors that are available to all
procedures and functions in the package.»
»

Mes commentaires:

1/ "more efficiently": "plus efficacement":

En fait, ce qu'il faut bien comprendre, c'est que sous Oracle, un schéma
c'est surtout un user de base de données. D'ailleurs, il porte
généralement le nom de l'user.

Sous PostgreSQL, c'est une entité logique qui sert à regrouper des
objets de base de données (tables, index, fonction, triggers, etc).
C'est pareil sous Oracle.

Pour avoir une entité logique sous Oracle, *recompilable*, on a créé le
PACKAGE. Comme ça n'était pas assez simple, on l'a scindé en deux
parties: le PACKAGE (header) et le PACKAGE BODY. Ceux qui connaissent le
C peuvent faire un parallèle heureux avec le .h et le .c d'un code
source. C'est pareil.

Donc 'plus efficacement': c'est une façon de dire: comme sous Oracle on
pouvait pas faire autrement que comme ça, on va dire à nos utilisateurs
que c'est efficace de faire comme ça...

Maintenant, c'est vrai que c'est une façon de regrouper les fonctions et
procédures.

Mais on aurait pu faire aussi des schémas distincts sous Oracle, comme
on le fait sous PostgreSQL.

2/ Affecter des privilèges de manière plus efficace

C'est vrai, sous Oracle. Sous PostgreSQL, c'est au niveau du schéma
qu'on le fera.

À noter que les privilèges Oracle sont bien plus subtils que ceux sous
PostgreSQL... Reste à savoir si on les utilise vraiment sous Oracle.

3/ Alors pour ce qui est de la compilation, effectivement, c'est
pratique sous Oracle. Sous PostgreSQL, on s'en moque.

4/ On s'en moque sous PostgreSQL, qui contrairement à Oracle, ne
mobilise la mémoire que s'il s'en sert. Et *sait la rendre* ensuite :-))

5/ La surcharge est tout à fait possible sous PostgreSQL. C'est à dire,
pour un même nom de fonction, son code peut changer, en fonction du
nombre ou de la nature des arguments.

6/ Variables globales et curseurs locaux au Package

Ça c'est un plus qu'à Oracle sur PostgreSQL. Par exemple, le curseur
"clients" peut être partagé par toutes les fonctions du package
"marketting". Sous PostgreSQL, il faudra copier la définition du curseur
dans toutes les fonctions.

Au final, pour moi, les Packages, sous PostgreSQL, on peut s'en passer.

C'est d'ailleurs probablement pour cela qu'ils n'existent pas sous
PostgreSQL...

> Mais comment font les programmeurs pour cela ?
>
> 1) Un schema pour chaque package,

C'est ce qu'on fait généralement quand on veut faire propre. En gros, un
schéma est un domaine, qui regroupe des entités cohérentes entre elles.

> ou alors
>
> 2) tout dans le même schéma avec la gestion à la main de grant
> execute sur schema.package1.fonction*, ..., schema.packageN.fonction*, etc ?

Rien ne vous empêche de faire sale, en effet :-))

Certains s'amusent à préfixer les objets, pour faire un simulacre de
Package. En pratique, ça n'a aucun autre intérêt que de voir les
fonctions alignées les unes sous les autres dans pgAdmin :)

note: schema.package.fonction: ça n'existe pas sous PostgreSQL.

> Question subsidiaire : Quid de ce que j'ai lu dans la Todo liste à
> propos de cette fonctionnalité ? Est-ce une problématique ou un demande
> qui revient souvent ou dois-je me faire une raison ?

Tout d'abord, vous recconaîtrez que cette *feature* est classée dans les
"Exotic Features".. Pour moi ça veut tout dire...

Et surtout, comprenez bien comment Pavel formule la demande:
«A package would be a schema with session-local variables,
public/private functions, and initialization functions»...

« Un package serait un schéma qui... »

Conclusion: la demande est exotique, un schéma, ça existe déjà sous
PostgreSQL.

En espérant avoir contribué à éclairer votre lanterne, je vous souhaite
une agréable soirée,

--
Jean-Paul Argudo
www.PostgreSQLFr.org

Bonjour,

> Cette réponse détaillée à l'avantage d'être limpide!

Je pense au contraire que j'en ai fait une tartine :)

> Par cette question je voulais surtout avoir une direction à suivre pour ne pas bidouiller, bref faire un truc propre!
> Je n'ai plus qu'à m'y mettre ...

De rien..

Comme l'a dit André Dupuis, EnterpriseDB est probablement une
alternative que vous devriez prendre en compte.

L'objectif d'EDB est de proposer un serveur PostgreSQL compatible avec
Oracle. Pour cela, ils ont développé une couche de compatibilité avec
Oracle au-dessus de PostgreSQL.

Leur intention est d'avoir un produit qui permette de faire fonctionner
une base Oracle directement dans EDB.

D'après la discussion que j'ai eu avec Simon Riggs cet été, à Prato en
Italie (pgdays), l'objectif est quasiment atteint et l'utilitaire de
migration est assez impressionnant (la migration serait *a priori*
automatique, clic/boutons dans une IHM, etc).

Cependant, EDB est un logiciel payant, basé su PostgreSQL. A vous de
juger, en fonction de vos contraintes et besoins.

Commencez la visite par là:

http://www.enterprisedb.com/

Un white paper dédié à la migration Oracle->EnterpriseDB:

http://www.enterprisedb.com/downloads/whitepapers/edb_compat_wp_final_102306.pdf

Et enfin, la page qui fait mal:

http://www.enterprisedb.com/shop.do?cID=10003&pID=10007

> Merci beaucoup, et certainement à bientôt !

Je vous en prie.

Merci à vous d'avoir considéré que PostgreSQL!

--
Jean-Paul Argudo
www.PostgreSQLFr.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bonjour

UPU.PostgreSQL a écrit :
| Bonjour,
| Cette réponse détaillée à l'avantage d'être limpide!
| Par cette question je voulais surtout avoir une direction à suivre pour ne pas bidouiller, bref
faire un truc propre!
| Je n'ai plus qu'à m'y mettre ...
| Merci beaucoup, et certainement à bientôt !
| Bir

Vous avez le projet ORACFE[1] sur pgFoundry qui va vous permettre de migrer en douceur, la plupart
des fonction d'Oracle 10g sont réécrites pour PostgreSQL (en C qui plus est)

Cordialement

Christophe Chauvet.

[1] http://pgfoundry.org/projects/orafce/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFHgzDcMl/S4ZhUIzERAthDAJ4v3ck27HsqXYn06P3ruQy+bdw/lQCfU5Ui
KPij8c2KPqgJ3/wSKwfHRqI=
=IkdE
-----END PGP SIGNATURE-----