Vous n'êtes pas identifié(e).
Par contre, je suis bien d'accord que le partitionnement dans PostgreSQL n'existe pas. Il existe un moyen de contourner ce manque et il faut en connaître les avantages et les inconvénients. Ce n'est qu'un contournement.
PostgreSQL™ offre un support basique du partitionnement de table.
Je trouve ça tout à fait honnête, crédible et objectif.
Bonjour.
Avez-vous essayé de lancer l'installation avec les droits administrateur ?
Sinon si le compte utilisateur postgres existe vous devez pouvoir relancer l'installeur en lui demandant de ne pas créer de compte mais d'en utiliser un.
ioguix a écrit :[...]
En attendant, plutôt que de détailler et insister sur les (je cite) "grandes lacunes de PostgreSQL", vous pourriez plutôt titrer "Obstacles et différences à prévoir lors d'une migration vers PostgreSQL" et les façons de les contourner ou alors bien souvent...l'autre façon de faire dans le monde PostgreSQL.
[...]Dommage, si vous passiez un quart de votre temps actuel accordé au pourissage pour écrire des choses constructives ou à participer de façon constructive à la communauté, on vous aurait peut-être cru quant à vos bons sentiments envers PostgreSQL.
Selon vous je ne devrais faire que des articles positif sur PostGreSQL et ne jamais parler de choses qui fasse... C'est amusant. Je ne sais pas pourquoi, mais cela me rappelle certains époque comme celle de l'URSS.
De plus et contrairement à ce que vous pensez j'agit dans les deux sens : critique + aide, mais il semble que vous ne lisiez que mes critiques..
Voici quelques un des articles "positifs" :
SQL et système d'information géographique (SIG)
Contraintes CHECK sur tables externe avec PostGreSQL
UDF POSTGRESQL : créer des fonctions PL/pgSQL avec de nombreux exemples - PARTIE 1 - fonctions scalairesA +
Pouvez-vous rediriger la sortie d'erreur de pg_dump vers un fichier texte ?
Bonjour.
Votre configuration doit pointer sur les binaires de la 8.4 (par le path à priori)
Vous devez la modifier pour pointer sur les nouveaux binaires clients de la 9.1
Un seul exemple me suffira, puisqu'ensuite je suppose que vous viendrez jouer de mauvaise foi ou répondrez à coté :
Il n'est pas non plus possible de savoir comment sont utilisés les index de la base et donc de supprimer les index inutilisés. Par exemple SQL Server propose la vue sys.dm_db_index_usage_stats pour connaitre l'utilisation de tous les index du serveur.
Il existe la même chose sur postgres, par exemple la vue pg_stat_user_indexes.
Pour votre "culture personnelle" également : http://docs.postgresqlfr.org/9.0/monitoring-stats.html
Maintenant, libre à vous de continuer votre arrogance et condescendance envers moi, cela me conforte (et apparemment je ne suis pas le seul) dans mon opinion sur votre crédibilité, et n'y répondrais plus.
Certains me prennent pour un affreux jojo anti PostGreSQL. Ce que bien évidemment je ne suis pas.
Mais connaître ses faiblesses c'est permettre le choix et surtout, comme c'est possible dans le monde libre, rajouter une contribution qui enrichit le système.
Au vu de vos articles, ce qu'il en ressort selon vous est qu'il ne faut jamais choisir postgresql, en donnant une argumentation plus que partiale. Si vous donniez toutes les informations et non celles qui vous arrangent, là effectivement cela enrichirait la discussion.
Ainsi, poster un article presque entièrement erroné, montrant votre méconnaissance de postgresql et un certain acharnement à le critiquer, sur un forum d'entraide pousse effectivement les gens à vous prendre pour "un affreux jojo anti Postgresql".
Je regrette par exemple qu'il faille payer pour mettre des tags (hint) de requêtes dans PostGreSQL par une pseudo philosophie obscure, alors que dans une version payante (EnterpriseDB) cela existe !
Je peux me tromper la dessus mais il me semble que c'est un choix des développeurs, motivés par le fait que :
1- Le SGBD est en grande majorité plus au courant que le développeur de la viabilité d'un plan d'exécution qu'un autre
2- Forcer l'utilisation d'un index peut se révéler quelques temps plus tard un mal plus qu'un bien selon l'évolution de la base, un index n'étant pas non plus une solution magique.
Au final, bien paramétrer sa base de donnée et s'assurer de bonnes statistiques n'a à ma connaissance jamais empêcher la résolution d'un problème de non utilisation d'un index sur postgresql.
Si cela ne vous convient toujours pas, libre à vous de proposer un patch proposant cette fonctionnalité, et ainsi enrichir le système, ou d'entamer des discussions avec les développeurs, chose beaucoup plus constructive.
Et si pour changer vous donniez aussi les avantages à ces migrations, ou que écriviez des choses vraiment objectives ?
Je sais, on dit "don't feed the troll" mais je trouve qu'il serait vraiment dommage que des utilisateurs du forum prennent de mauvaises décisions sur de mauvais conseils...
(Les données des utilisateurs 1 et 2 sont mélangés => on n'a pas une suite de 1, puis une suite de 2).
Bien sur ces tests étaient sous SQL Server 2005 sans mises à jour, je ne sais pas si cela a changé depuis.
L'ordre de visualisation des lignes correspond à l'ordre d'utilisation du compteur associé lors de l'insertion. Sur postgresql, le résultat sera équivalent car les séquences n'ont aucune contrainte de transaction pour assurer leur unicité, et peuvent ainsi se "mélanger" lors de plusieurs appels concurrents.
Bonjour.
Ces 3 versions sont stables mais de version majeure différente (sur postgresql les 2 premiers chiffres forment la version majeure).
Je vous conseillerai la 9.1.1, celle-ci bénéficiant des dernières optimisations et nouveautés.
J'avoue que je ne m'y connais vraiment pas en encodage.
A tout hasard, faire un set client_encoding to 'UTF-16LE' au lieu de 'LATIN1' en début de procédure stockée ne pourrait pas résoudre le problème ?
5. J'ai essayé de créer une transaction contenant une autre transaction (cela s'appelle nested transaction d'après ce que j'ai lu sur internet) en reprenant l'exemple précédent :
BEGIN; INSERT INTO t1(date, vala, valb, valc) VALUES(NOW(), 1, 1, 1); BEGIN; UPDATE t1 SET date=NOW() WHERE id = 1; COMMIT; COMMIT;J'ai ce message qui apparaît :
ATTENTION: une transaction est déjà en cours
ATTENTION: aucune transaction en coursLa requête a été exécutée avec succès en 15 ms, mais ne renvoie aucun résultat.
Pourquoi un message d'avertissement apparaît ? N'a-t-on pas le droit de faire cela en temps normal ?
Si c'est pour pouvoir annuler une partie des requêtes en cours de traitement, vous pouvez mettre des points de sauvegarde à l'intérieur d'une transaction et ensuite choisir d'annuler ce qui a été fait depuis un des points de sauvegarde.
L'alias est interdit pour les SET mais absolument pas dans le WHERE.
Je pense que le problème vient du
UPDATE alias
...
FROM table AS aliasVous devriez plutôt faire :
UPDATE table as ALIAS ....
FROM
et JOIN si besoin
et ça devrait résoudre le problème.
Avez vous lancé l'invite de commande en mode administrateur ? sinon votre compte administrateur n'aura que des privilèges utilisateurs.
Je n'utilise pas trop le one clic installer, mais je pensais qu'il créait un compte puis lançait le initdb avec le compte qu'il venait de créer. C'est donc à partir de ce compte la qu'il faut lancer le initdb (vous pouvez créer un fichier .bat avec les bonnes options et faire un shif-clic droit dessus puis "exécuter en tant que").
La politique de sécurité vous refusant un compte utilisateur mais vous permettant d'utiliser un compte administrateur est quelque peu surprenante, mais il a sans doute ses raisons.
En tout cas, tant mieux si vous pouvez avancer avec cette solution.
Autant pour moi, désolé
Cette erreur provient d'une modification de PostGIS et non Postgresql.
Vous pouvez utiliser "NOT ST_Equals(OLD.the_geom,NEW.the_geom)" à la place de l'opérateur !=
Désolé, c'était la première (et j'espère dernière fois) que j'utilisais powershell, et je ne connais vraiment pas du tout ce langage.
Après quelques recherches, je suis tombé sur cet article :
http://powershell-scripting.com/index.p … 89&catid=5 et j'ai un peu adapté.
La syntaxe reste lourde et peu documentée je trouve, mais quand on n'a pas le choix ... 
Vous pouvez utiliser l'étape intermédiaire en powershell suivante
Get-Content .\fichier.txt | select-string . | where { $_.linenumber -gt 2 } > final.txtet ensuite importer le final.txt en utilisant un délimiteur ','
Est-ce un traitement unique ou un import régulier ?
Quelle est la taille du fichier ?
D'où provient le fichier et pouvez-vous changer sa génération ?
Quelle est la structure exacte de la table résultant de l'importation ?
Vous pouvez utiliser une syntaxe du genre :
SELECT res[1],res[2] ....
FROM (
SELECT cast( '{' || champ || '}' as varchar[]) as res) FROM importation
) sql
et ainsi avoir vos données accessibles séparément.
Il est possible d'utiliser un delimiteur lors de l'importation d'un fichier (COPY nom_table FROM fichier.txt WITH DELIMITER ',') et ainsi avoir un champ pour chaque élément.
Cependant il vous faudra modifier le champ température soit lors de la génération du fichier texte, soit après l'importation pour enlever le "°C".
Lors de l'installation, vous avez un répertoire ou sont installés les exécutables de Postgresql, mais vous pouvez choisir un répertoire différent pour le DATA, et il faut alors s'assurer que celui-ci a également les droits en écriture. Il faut aussi s'assurer que l'utilisateur postgres ne soit pas administrateur.
Une fois ceci vérifié, sans le log de l'installeur, vous pouvez essayer un initdb.exe -D "repertoire_data" (soit un répertoire spécifique, soit le répertoire postgres\data) et voir si celui-ci vous renvoie plus d'informations.
Un simple begin au début de vos commandes ne suffit pas ?