Skip site navigation (1) Skip section navigation (2)

Re: Oracle => Postgresql

From: "UPU(dot)PostgreSQL" <UPU(dot)PostgreSQL(at)upu(dot)int>
To: "Jean-Paul Argudo" <jean-paul(at)argudo(dot)org>,"UPU(dot)PostgreSQL" <UPU(dot)PostgreSQL(at)upu(dot)int>
Cc: "A(dot) DUPUIS" <andre(dot)dupuis(at)u-bourgogne(dot)fr>,<pgsql-fr-generale(at)postgresql(dot)org>
Subject: Re: Oracle => Postgresql
Date: 2008-01-08 06:32:40
Message-ID: 4D6EFE7820D74D4CA77EF568FB6039AB0162C767@HERMES.upu.ch (view raw or flat)
Thread:
Lists: pgsql-fr-generale
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

In response to

Responses

pgsql-fr-generale by date

Next:From: Jean-Paul ArgudoDate: 2008-01-08 08:10:16
Subject: Re: Oracle => Postgresql
Previous:From: Jean-Max ReymondDate: 2008-01-08 06:20:10
Subject: Votons pour Postgres

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group