Vous n'êtes pas identifié(e).
Un moyen de ne pas incrémenter si échec d'INSERT ?
Bonjour,
Il suffit de choisir le type de colonne SERIAL pour la colonne ID et PostgreSQL créera une séquence.
Dans le fichier CSV, ne pas prendre la colonne ID, PostgreSQL se charge de tout.
A chaque insertion dans la table ID sera auto-incrémenté.
Trop cool, ça fonctionne.
Grand merci.
Pas de PK...
Bonjour,
Je cherche les doublons avec ce query
WITH CTE AS (SELECT art_id,
prix,
maj,
ROW_NUMBER() OVER(PARTITION BY art_id,
maj
ORDER BY maj,prix DESC) AS DuplicateCount
FROM historique_prix
SELECT * FROM CTE WHERE DuplicateCount > 1
Et voici le résultat
|art_id|prix|maj|duplicatecount|
|------|----|---|--------------|
|6739|94.00|2021-09-01 15:54:47.000|1|
|6739|88.00|2021-09-01 15:54:47.000|2|
|6739|95.00|2021-09-20 22:29:47.000|1|
|6739|96.00|2021-09-30 10:29:40.000|1|
|6739|93.00|2021-10-04 09:26:22.000|1|
|6739|91.00|2021-10-04 09:26:22.000|2|
|6739|92.00|2021-10-05 17:23:03.000|1|
|6739|93.00|2021-10-08 10:50:33.000|1|
|6739|87.00|2021-10-11 10:27:02.000|1|
|6739|88.00|2021-10-15 08:59:32.000|1|
|6739|87.00|2021-10-15 10:29:06.000|1|
|6739|84.00|2021-10-25 10:28:42.000|1|
|6739|85.00|2021-10-26 10:28:14.000|1|
|6739|84.00|2021-10-29 08:58:25.000|1|
|6739|82.00|2021-11-01 09:32:21.000|1|
|6739|83.00|2021-11-12 12:52:48.000|1|
|6739|84.00|2021-11-17 09:49:58.000|1|
|6739|85.00|2021-11-23 10:04:03.000|1|
|6739|84.00|2021-11-30 11:34:21.000|1|
|6739|85.00|2021-12-20 11:26:21.000|1|
|6739|84.00|2021-12-24 13:42:04.000|1|
|6739|83.00|2022-01-13 10:44:55.000|1|
|6739|86.00|2022-01-17 11:16:58.000|1|
|6739|89.00|2022-01-18 16:33:24.000|1|
|6739|86.00|2022-01-18 16:33:24.000|2|
|6739|90.00|2022-01-18 16:35:24.000|1|
|6739|86.00|2022-01-18 16:35:24.000|2|
|6739|91.00|2022-01-18 16:38:40.000|1|
|6739|90.00|2022-01-18 16:38:40.000|2|
|6739|93.00|2022-01-27 10:57:11.000|1|
|6739|88.00|2022-01-29 14:56:44.000|1|
|6739|87.00|2022-02-01 10:56:47.000|1|
|6739|86.00|2022-02-04 09:49:44.000|1|
|6739|87.00|2022-02-24 11:04:31.000|1|
|6739|88.00|2022-02-25 12:38:54.000|1|
|6739|89.00|2022-03-02 13:37:14.000|1|
|6739|90.00|2022-03-07 14:02:54.000|1|
|6739|89.00|2022-03-10 10:13:31.000|1|
|6739|90.00|2022-03-14 09:40:04.000|1|
|6739|89.00|2022-03-15 11:10:32.000|1|
|6739|90.00|2022-03-28 09:49:49.000|1|
|6739|89.00|2022-03-29 11:50:02.000|1|
|6739|88.00|2022-03-30 11:49:29.000|1|
|6739|89.00|2022-04-01 11:05:08.000|1|
|6739|86.00|2022-04-04 10:58:34.000|1|
|6739|87.00|2022-04-05 10:58:35.000|1|
|6739|88.00|2022-04-08 09:37:39.000|1|
|6739|87.00|2022-04-11 09:37:46.000|1|
|6739|88.00|2022-04-13 09:37:37.000|1|
|6739|87.00|2022-04-14 16:47:16.000|1|
|6739|85.00|2022-04-19 10:06:22.000|1|
Mais si j'essaie de supprimer les doublons, j'ai une erreur.
WITH CTE AS (SELECT art_id,
prix,
maj,
ROW_NUMBER() OVER(PARTITION BY art_id,
maj
ORDER BY maj,prix DESC) AS DuplicateCount
FROM historique_prix WHERE art_id = 6739)
DELETE FROM CTE WHERE DuplicateCount > 1
Et voici l'erreur.
SQL Error [42P01]: ERREUR: la relation « cte » n'existe pas
Position : 300
Error position: line: 9 pos: 299
Je ne comprends pas...
A l'aide svp.
Merci d'avance.
Bonjour,
Je te mets sur la voie...
Ta requête cherche les sociétés dont le nom est EGAL à 'Bike'
Je te laisse réfléchir.
Une piste...
Comme il y a un espace entre Program et Files
Est-ce le nom du chemin complet est bien entre guillemets qlq part...
J'ai trouvé...
Voici la ligne GRANT correcte.
EXECUTE 'GRANT SELECT ON LARGE OBJECT ' || oid_data.id || ' TO ' || user_for_grant;
Parfait ça fonctionne.
Merci.
Mais il faut GRANT individuellement pour chaque oid
J'essaie de faire une petite fonction pour le faire sur tous les oid d'un coup mais j'ai une erreur de syntaxe bizarre
--------------- SQL ---------------
CREATE OR REPLACE FUNCTION public.grant_select_oid (
user_for_grant text
)
RETURNS void AS
$body$
DECLARE
oid_data RECORD;
BEGIN
FOR oid_data IN
SELECT fichier_data AS "id"
FROM articles_fichiers
WHERE fichier_data IS NOT NULL
UNION
SELECT fichier_data_mini AS "id"
FROM articles_fichiers
WHERE fichier_data_mini IS NOT NULL
LIMIT 10
LOOP
GRANT SELECT ON LARGE OBJECT oid_data.id TO user_for_grant;
-- RAISE NOTICE 'user = %, oid = %', user_for_grant, oid_data.id;
END LOOP;
END;
$body$
LANGUAGE 'plpgsql'
VOLATILE
CALLED ON NULL INPUT
SECURITY INVOKER
PARALLEL UNSAFE
COST 100;
---------- MESSAGE D'ERREUR --------
ERREUR: erreur de syntaxe sur ou près de « oid_data »
LINE 15: GRANT SELECT ON LARGE OBJECT oid_data.id TO user_for_grant...
^
Une idée ?
Merci d'avance.
Bonjour,
Mais je suis obligé d'activer l'option lo_compat_privileges pour qu'un utilisateur "limité" puise lire les données des "Large Objects". Malheureusement l'activation de cette option ignore les restrictions d'accès en lecture ET en écriture...
L'utilisateur a pourtant le droit de lire colonnes oid correspondantes mais cela ne suffit pas.
J'imagine qu'il faut lui donner le droit de lire les colonnes correspondantes aux données des "Large Objects" dans les tables système.
Cela me permettrais de ne pas devoir activer cette option et autoriser la lecture seule des "Large Objects" des mais je ne vois pas comment faire...
Merci d'avance.
Bonjour,
Perso j'utilise EMS SQL Manager for PostgreSQL en version Lite et cela donne le nom (donné lors de la création de la fonction/procédure) et le type de chaque paramètre.
ça ne fonctionnait pas...
Voici ce que j'ai fais :
- déinstallation de PG14
- installation PG14
- avant de me connecter j'ai remplacé le scram-sha-256 par md5 dans le fichier pg_hba.conf
- restoration de mon backup de cluster PG14 (fait avec pg_dump_all)
Et la tout fonctionne parfaitement.
Dans le fichier pg_hba.conf, il y a ceci.
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all scram-sha-256
# IPv4 local connections:
host all all 127.0.0.1/32 scram-sha-256
# IPv6 local connections:
host all all ::1/128 scram-sha-256
# Allow replication connections from localhost, by a user with the
# replication privilege.
local replication all scram-sha-256
host replication all 127.0.0.1/32 scram-sha-256
host replication all ::1/128 scram-sha-256
Sans l'option -W, psql va cherche le mot de passe dans le fichier %appdata%/postgresql/pgpass.conf
J'ai vérifié dans le fichier, le mot de passe est correct...Et j'ai utiliser l'option -W pour forcer la demande.
Je ne comprends pas ce qui se passe ...
Avec PG13 le mot de passe était en md5 par défaut et avec PG14 c'est scram-sha-256... Ce serait lié à mon problème ?
Bonjour,
J'ai un serveur sous Windows 10 Pro avec un serveur de production PG13 qui fonctionne nickel. J'ai fais un backup (pg_dumpall) du cluster pour faire des tests sous PG14.
J'installe PG14 et j'essaie de faire un restore avec psql.
Impossible de m'y connecter...
psql -U postgres -p 5433 -W
Mot de passe :
psql: erreur : la connexion au serveur sur « localhost » (::1), port 5433 a échoué : FATAL: authentification par mot de passe échouée pour l'utilisateur « postgres »
Je fais toujours comme cela pour tester les nouvelles versions...cela a toujours fonctionner...
Je n'ai touché à aucun fichier de configuration après l'installation et suis en direct sur le serveur.
Une idée ?
Merci d'avance.
Voici l'erreur dans l'application Java, il n'y a rien dans les log de PostgreSQL
Message:
org.postgresql.util.PSQLException: Une erreur d'entrée/sortie a eu lieu lors d'envoi vers le serveur.
Level:
SEVERE
Stack Trace:
Une erreur d'entrée/sortie a eu lieu lors d'envoi vers le serveur.
Mais je viens de comprendre...
Au bout de 30mins ce PC se mets en veille...
Du coup, au réveil, les connexions ouvertes sont rompues...tout simplement.
Bonjour,
J'ai un serveur PostgreSQL 13.3 sous Windows 10 Pro et je m'y connecte via une application Java Desktop avec le connecteur JDBC et via un site Internet.
Mais sur un seul de mes PC en réseau local , l'application Java me rapporte une erreur E/S au bout de +- 1h. Lorsque cela se produit, je relance l'application et cela refonctionne correctement sans rien changer d'autre. A ce moment précis les autres PC où l'application est en fonctionnement ne posent aucuns problèmes.
J'ai testé mon application à partir de nombreux autres PC, sur le réseau local ou à distance ne provoque jamais cette erreur...
J'ai ajouter le "tcpKeepAlive" a true dans les paramètres de connexion JDBC mais cela ne change rien.
Une piste ?
Merci d'avance.
oui avec dblink_connect
J'ai juste dis que c'est possible avec EMS SQL Manager... est-ce que c'est souhaitable...c'est une question de point vue. L'intérêt est faible je pense au vu du coût.
Comme le dit rjuju cela va bien sûr recréer la table avec toutes les implications décrites...
Si la table est volumineuse...préparez-vous à patienter...
C'est possible sans perte de données avec EMS SQL Manager for PostgreSQL, même avec la version Freeware gratuite.
Il faut autoriser PostgreSQL a passer le pare-feu (celui de Windows ou celui que vous avez installé...Norton, etc...)
Désolé le lien de la doc était incorrect...c'est corrigé
Pour info utiliser pg_dump comme d'habitude avec en plus, par exemple, --jobs=4
Plusieurs dizaines de milliers de tables...c'est énorme.
Je suis curieux de savoir...il y a quoi dans la base ?
Il n'y aurait pas un soucis de modélisation/analyse...
Autoriser l'application PostgreSQL à communiquer à travers le pare-feu du Windows dans lequel il se trouve.
Il n'y a toujours pas de solution officielle pour installer PostgreSQL directement dans un serveur Synology ?