Vous n'êtes pas identifié(e).
Merci de votre retour,
Une petite différence tout de même, le nouvel environnement dispose de la version 15 de postgresql, et le précédent avait le même type d'OS, mais une version 14 de PostgreSQL.
Est-ce malgré tout possible ?
D'avance merci de votre retour.
Cdts.
Bonjour,
Suite à un crash du disque système Linux, j'ai procédé à une nouvelle installation de l'environnement Linux et installé le moteur SGBD actuel PostgreSQL15.
Je dispose toujours des disques de stockage du SGBD, mais pas de dump, et voulais savoir, si une possibilité existe pour réactiver cette base de donnée existante, à partir de l'arborescence présente ?
Le contenu du SGBD n'étant pas de grande importance, je pourrai très bien recréer la base de données, mais avant d'entreprendre cette opération, j'aurai voulu votre avis sur ce sujet.
D'avance merci de votre retour.
Merci de l'information,
Le package est à présent installé.
@+
Merci de votre retour.
Merci de me rappeler le site francophone.
Je dispose d'une distribution de type Almat.
Pouvez-vous m'indiquer un lien pour télécharger ce package ?
(Site de Postgres ?)
D'avance merci de votre retour.
Cordialement.
I'd like to install plugin debugger on Linux postgreSQL 14 server ?
The plugin library : plugin_debugger.so is not present on postgreSQL 14 server
is a package available for install it ?
What is the process to do it ?
Help will be appreciate.
Thank's in advance.
Merci de la réponse.
Je vais pouvoir à présent poursuivre mon analyse.
Bon Week-end.
Merci du retour.
Je viens de me rendre compte que je ne passais pas en paramètre de la fonction, l'oid du trigger mais le tgrelid de la table pg_trigger.
En passant bien l'oid du trigger, la fonction renvoie bien un résultat comme ci-dessous :
[ code ]
select pg_get_triggerdef ('32913'::OID);
pg_get_triggerdef
---------------------------------------------------------------------------------------------------------------------------
CREATE TRIGGER trg_tabbdd AFTER INSERT OR DELETE ON user.tabbdd FOR EACH ROW EXECUTE PROCEDURE fct_trg_tabbdd()
(1 ligne)
[ /code ]
Je m'attendais également à voir le code source la fonction associée au trigger.
Qu'en est t'il exactement du résultat fourni par cette fonction ?
Merci de m'éclairer.
Cordialement.
Bonjour à tous,
Je cherche, pour une analyse de l'environnement, à ressortir le code source des objets SQL de type fonction ou trigger.
Pour les objets de type fonction, j'utilise la fonction : pg_get_functiondef à laquelle je fournis en paramètre l'oid de la fonction, et qui me renvoie le code source de ma fonction. C'est bien le résultat que j'attendais.
Pour les objets de type trigger, j'utilise la fonction : pg_get_triggerdef à laquelle je fournis en paramètre l'oid du trigger, mais je n'obtiens aucun résultat (null)
Le problème est t'il connu ? ou bien il faut procéder différemment ?
Tout éclairage sera le bienvenu.
D'avance merci.
Cordialement.
Bonjour à tous,
merci de votre retour.
J'ai, depuis l'envoi de ce post, poursuivi mes recherches et abouti également à la dernière proposition de Marc Cousin, qui me parait la plus rationnelle.
Encore merci.
Bonne journée.
Bonjour à tous,
Je cherche à convertir une chaine numérique vers un type oid.
J'ai tenté la commande to_number ('123456', '999999')::oid qui n'est pas acceptée.
Avez-vous la solution pour réaliser cette opération ?
D'avance merci de votre aide.
Cordialement.
Bonjour,
Après lecture sur l'utilisation des locales dans PostgreSQL, il est préférable de s'affranchir de code utilisant des locales.
J'ai donc modifié le code dans ce sens.
Merci du retour.
J'avais bien compris qu'il s'agissait de ce paramètre, mais au vu du résultat de la commande show pour e paramètre, je ne vois la façon de modifier ce paramètre dans le cas de redéfinition du caractère décimal :
French_France.1252 (résultat obtenu sur un environnement)
int=> show lc_numeric;
lc_numeric
-------------
fr_FR.UTF-8
(résultat obtenu sur un autre environnement).
Pouvez-vous m'éclairer davantage ?
D'avance merci.
Bonjour,
Je cherche la façon de redéfinir la valeur de la constante du caractère décimal à utiliser lors d'une session.
Je suis confronté à un problème d'interprétation du caractère décimal lors de l'utilisation de la fonction to_number, utilisant le formattage : '999999D99'.
Le caractère 'D' de la chaine de formattage s'appuie sur la locale définissant le caractère décimal à utiliser.
Aussi, je voudrai connaître la façon de redéfinir cette locale. (Je suppose qu'il s'agit de la fonction SET, mais je n'ai pas trouvé le paramètre correspondant à celà).
J'ai vu également que l'on peut indiquer le caractère décimal à utiliser dans la chaine de formattage ('999999.99' pour le point, ou '999999,99' pour la virgule).
D'avance merci de votre retour.
Bonjour à tous,
Je ne suis pas certain d'être sur le bon forum pour le problème que je rencontre.
Je viens d'installer un nouvel environnement utilisant PostgreSQL 10.9 et utilise l'interface utilisateur PEM (PostgreSQL Entreprise Manager)
Backend version
PostgreSQL 10.9, compiled by Visual C++ build 1800, 64-bit
Apache version
Apache/2.4.39 (Win32) mod_wsgi/4.4.23 Python/3.4.6 OpenSSL/1.0.2r
App version
7.8.0 (schema: 201905081)
Schema version
201905081
User
dev
Python version
3.4.6
Flask version
1.0.2
Lors d'un essai de debugage d'une fonction, j'ai le message d'erreur suivant après avoir saisi les paramètres de la fonction et validé :
local variable 'debugger_version' referenced before assignment
Tout éclairage sur les solutions à ce problème sera le bien venu.
D'avance merci.
Bonjour,
Je rencontre un problème lors d'un ordre INSERT d'une clé déjà présente. (La clé vient d'être enregistrée par un autre processus en parallèle)
Je voulais utiliser la clause ON CONFLICT afin de faire une mise à jour (somme de la valeur fournie à la valeur déjà présente), mais je rencontre une erreur d'utilisation.
Ci-dessous, la table exemple à alimenter :
Colonne | Type | Collationnement | NULL-able | Par défaut
------------+-----------------------+-----------------+-----------+------------
domaine | character varying(10) | | not null |
struct | character varying(40) | | not null |
datjour | date | | not null |
jour | character varying(1) | | not null |
codecpt | character varying(10) | | not null |
valeura | character varying(40) | | |
codemodele | character varying(10) | | |
typedata | character varying(1) | | |
valeurd | integer | | |
Index :
"i_matable" PRIMARY KEY, btree (domaine, struct, datjour, jour, codecpt)
L'instruction INSERT que je voudrai réaliser. Dans l'exemple, je voudrais ajouter la valeur 10 si la clé est présente, sinon insérer la valeur 10 pour la clé fournie.
INSERT INTO MATABLE (DOMAINE,
STRUCT,
DATJOUR,
JOUR,
CODECPT,
VALEURA,
CODEMODELE,
TYPEDATA,
VALEURD)
VALUES ('STRUCTURE',
'XXXXXX',
TO_DATE ('20190801', 'YYYYMMDD'),
'1',
'TOG',
' ',
' ',
'1',
10)
ON CONFLICT DO UPDATE SET VALEURD = VALEURD + 10
WHERE (DOMAINE = 'STRUCTURE')
AND (STRUCT = 'XXXXXX')
AND (DATJOUR = TO_DATE ('20190801', 'YYYYMMDD'))
AND (JOUR = '1')
AND (CODECPT = 'TOG');
Le message d'erreur que j'obtiens :
ERREUR: ON CONFLICT DO UPDATE requiert une spécification d'inférence ou un nom de contrainte
19 : ON CONFLICT DO UPDATE SET VALEURD = VALEURD + 10
^
E : Par exemple, ON CONFLICT (nom_colonne)
Il semble manquer une information dans la clause ON CONFLICT, aussi que faut t'il indiquer ?
D'autre part vais réussir à obtenir le résultat souhaité (20) ?
D'avance merci de votre retour.
Merci du retour.
J'ai positionné la valeur de ce paramètre à terse, mais cela n'a pas d'effet sur l'aspect verbeux des messages.
Bonjour,
Je cherche à réduire les messages produits lors de l'utilisation des commandes RAISE NOTICE.
En effet, lorsque j'utilise la commande RAISE NOTICE, le message produit s'affiche bien, mais accompagné du contexte dans lequel le message a été généré (nom de la fonction, ...), ce qui rend parfois trop verbeux les messages lors des mises au point d'un code.
Est t'il possible d'éviter l'affichage du contexte, de façon à avoir uniquement le message enregistré dans la commande RAISE NOTICE ?
D'avance merci de votre retour.
Bonjour,
Pour des besoins de performances (durées de traitement) j'envisage de lancer en tâches de fond sur un environnement Linux, plusieurs commandes psql pouvant s'exécuter indépendamment les unes des autres.
Lors des essais que j'ai pu réaliser, les différents traitements sont bien parallélisés (les N processus s'exécutent simultanément). Chaque traitement exécute la même procédure stockée, mais avec des paramètres différents.
J'espérais un gain de temps en adoptant ce procédé, mais je n'ai pas obtenu le résultat escompté. Mon collègue DBA me fait remarquer qu'il n'y a un processus SGBD sollicité sur le serveur hébergeant PostgreSQL, à ma grand surprise. Je pensais qu'un processus distinct PostgreSQL aurait été associé aurait été associé à chaque processus exécutant psql.
Est ce un fonctionnement normal, ou bien je ne procède pas correctement pour obtenir le résultat souhaité.
Un éclairage sur le sujet sera le bien venu.
D'avance merci.
Bonjour,
j'ai tenté de me connecter au dépôt CVS de PostgreSQL, sans y parvenir.
Ci-dessous, les informations de login utilisées en provenance de l'Annexe F. Dépôt CVS :
cvs -d :pserver:anoncvs@anoncvs.postgresql.org:/projects/cvsroot login
Les informations ne seraient plus à jour, ou bien le problème de connexion serait local.
D'avance merci de votre retour.
Merci du retour,
Je viens de trouver l'explication au problème.
Il s'agit de la présence de valeurs nulles qui rendent le résultat du test incorrect.
J'ai résolu le problème en utilisant la fonction COALESCE appliquée à la valeur passée en paramètre.
Bonjour à tous,
Je m'étonne du comportement d'une requête utilisant une fonction comme critère de sélection.
La fonction utilisée fait le contrôle d'une chaîne date passée en paramètre, et restitue TRUE si la date est correcte ou FALSE dans le cas contraire.
Utilisée dans la requête ci-dessous, celle-ci retourne un bon résultat selon la valeur du paramètre passé.
select is_date ('');
is_date
---------
f
(1 ligne)
select is_date (' ');
is_date
---------
f
(1 ligne)
select is_date ('20190121');
is_date
---------
t
(1 ligne)
La date passée en paramètre est attendue au format : YYYYMMDD
Utilisée dans une clause Where d'une requête de type SELECT, la fonction ne semble pas retourner le même résultat.
Ci-dessous, la requête utilisée :
SELECT C.DAT
FROM MA_TABLE C
WHERE NOT IS_DATE (C.DAT);
dat
-----
(0 ligne)
La table MA_TABLE comporte un champ DAT de type chaîne de caractères qui n'est pas toujours renseigné ou ne correspond pas à une date au format : YYYYMMDD.
La requête me retourne 0 lignes, malgré le champ DAT ayant un contenu incorrect, comme si le code de la fonction renvoyait toujours TRUE, ce qui n'est pas le cas.
Ci-dessous, le code de la fonction utilisée :
CREATE OR REPLACE FUNCTION IS_DATE (P_VAR VARCHAR)
RETURNS BOOLEAN
AS $$
DECLARE
V_Dat DATE;
BEGIN
V_Dat := TO_DATE (P_VAR, 'YYYYMMDD');
RETURN TO_CHAR (V_Dat, 'YYYYMMDD') = P_VAR;
EXCEPTION
WHEN OTHERS THEN
RETURN FALSE;
END;
$$ LANGUAGE plpgsql;
D'avance merci de votre retour pour tout éclairage sur le sujet.
Cordialement.
Merci du retour,
.
La librairie est bien indiquée dans le shared_preload_libraries et l'extension a bien été installée dans chaque base de données. (Les fonctions du debugger apparaissant bien dans la liste des fonctions depuis le navigateur).
Par contre, je ne vois pas de ligne preload_libraires dans le fichier de configuration postgresql.conf. Est présente uniquement la ligne : shared_preload_libraries (renseignée).
Cela veut t'il dire qu'il faut la rajouter manuellement, ou bien le définir ailleurs ?
.
D'avance merci de m'éclairer.
.
Cordialement.
Bonjour,
J'ai activé le module de debuggage dans une base de données (commande : CREATE EXTENSION pldbgapi), mais le choix debuggage de la fonction n'apparait pas dans le menu popup qui s'affiche par un clic droit sur la fonction
depuis le navigateur d'objets.
Les différentes fonctions utilisées pour le debuggage (pldbg_*) dans la base sont pourtant bien présentes.
Que manque t'il ?
Quelle action doit t'on mener pour le faire apparaître ?
Pour information, le module de debuggage a déjà été installé dans d'autres bases situées sur le même serveur, et le choix debuggage apparait bien dans le menu popup (clic droit sur une fonction)
D'avance merci de votre retour.
Cordialement.
Bonjour,
Je cherche à activer le module de debugger de POSTGRESQL (Version 10). (Windows 10 en 64 bits)
Je suis la procédure indiquée ci-dessous :
-- Debut Installation module de debuggage.
------------------------------------
The package includes EnterpriseDB's pl/pgsql debugger plugin which may be used by the debugger UI in pgAdmin to help with development of your database functions.
The debugger plugin is disabled by default for performance reasons.
To enable it, follow the following steps:
Edit the postgresql.conf file in the data directory and modify the shared_preload_libraries config option to look like the following, if running on Linux or Mac:
shared_preload_libraries = '$libdir/plugins/plugin_debugger.so'
or if you are on Windows:
shared_preload_libraries = '$libdir/plugins/plugin_debugger.dll'
Restart the PostgreSQL server.
Après avoir décommenté la ligne : shared_preload_libraries = '$libdir/plugins/plugin_debugger.dll' je relance les services PostgreSQL, mais les services s'arrêtent.
Il n'y a pas de message dans le fichier log de PostgreSQL, mais il en existe dans le gestionnaire d'événements de Windows :
Nom du journal :Application
Source : PostgreSQL
Date : 20/11/2018 17:59:32
ID de l’événement :0
Catégorie de la tâche :Aucun
Niveau : Erreur
Mots clés : Classique
Utilisateur : N/A
Ordinateur :
Description :
2018-11-20 17:59:32.644 CET [1212] FATAL: n'a pas pu accéder au fichier « $libdir/plugins/plugin_debugger.dll » : No such file or directory
Pourtant la librairie concernée : plugin_debugger.dll est bien présente dans le répertoire : ......\10\lib.
Vers quoi pointe $libdir ?
Comment peut t'on vérifier l'emplacement référencé par : $libdir et le modifier si nécessaire (requête ?)
Toute aide sera la bienvenue.
D'avance merci pour votre aide.
Merci de votre retour.
C'est en effet vers la suggestion proposée par dverite que je m'orientais afin de traiter le sujet.
Cette problématique pourrait être enregistrée dans la roadmap de Postgresql, et de façon plus générale, un moyen natif et plus élaboré pour le chargement de données à partir de fichiers, tel que le fait magnifiquement le sqlloader d'Oracle.