Salut gleu,

C'est un problème souvent rencontré lors des migrations j'ai l'impression (à partir de bases de données qui ne connaissent pas le type booléen, quel dommage...).
Du coup, on est obligé de réécrire toutes les requêtes.

Y'a pas de truc ou d'astuce alors?
(il me semble que le problème c'est que le driver JDBC d'Oracle convertit automatiquement les booléens en entiers, d'où les problèmes de migration ensuite. À vérifier)

À quoi correspondent les 2 premières lignes? Est-ce que ce sont des informations que vous souhaitez conserver dans votre base, ou non? (il semblerait que non, vu que vous supprimer les premières lignes?)
Si non, il serait certainement plus simple de supprimer ces lignes du fichier avant import? Et ensuite on peut l'importer avec COPY directement.
Si oui, alors pourriez-vous expliquer ce que vous souhaitez en sortie? (structure de la ou des tables à la fin du traitement).

Pourquoi ne faites-vous pas cela dans l'application? (lorsque l'utilisateur saisit une nouvelle station d'étude). C'est beaucoup plus simple.
Pourquoi mettre tout dans la même table? J'imagine qu'il pourrait y avoir une sorte de table de référence avec la liste des codes de lieu dit. Une autre table contiendrait les stations d'étude (une station correspond à un lieu dit + une altitude).
Si j'ai bien compris votre besoin...

Je suppose que vous êtes débutant en bases de données?

J'ai du mal aussi.

Alors  j'ai fait le test :
cela fait un produit cartésien, sauf que pour les lignes où la condition n'est pas respectée, on n'a rien dans les colonnes de la table "de droite".

Exemple :

test=# select * from table1 left join table2 on table1.valeurs1 = 'b';
 idtable1 | valeurs1 | idtable2 | valeur2
----------+----------+----------+---------
        1 | a        |          |
        2 | b        |        1 | 1
        2 | b        |        2 | 2
        2 | b        |        3 | 3
        2 | b        |        4 | 4
        3 | c        |          |
        4 | d        |          |
        5 | e        |          |
        6 | f        |          |
(9 lignes)

J'avoue que je ne vois pas l'intérêt du truc, comme cela.

C'est exactement ce que je voulais dire . Il est assez fréquent qu'on se rende compte, en remplaçant les vues par leur requête, que des tables sont inutilement jointes plusieurs fois. C'est en cela que  je disais qu'il faut faire attention quand on joint des vues et des tables.

D'autre part, l'utilisation de COALESCE comme condition de jointure me laisse penser qu'il y a un problème dans le modèle de données, ou dans la requête elle-même. Je n'ai jamais vu  de cas où on avait besoin d'une telle chose, même dans des cas très tordus.

La date n'est stockée sous aucun format. C'est juste une date.
http://docs.postgresql.fr/9.1/datatype-datetime.html

Afin que nous puissions vous aider, comment insérez-vous la date dans la base (outil, code?), et comment la récupérez-vous?

Je vous conseille de travailler d'abord sur la requête avant de vous pencher sur les paramètres. Il y a très probablement des améliorations importantes à faire. Voir ce que j'ai écrit 1 min avant votre question (les messages se sont croisés sans doute)

Ah gleu c'est malin, je n'y avais pas pensé . Par contre, il n'est pas possible de faire cela de manière générique, je suppose? (la demande d'Olivier précise qu'il voudrait ne pas saisir les colonnes).

Sinon, Olivier, je trouve cette demande très étrange. Je ne comprends pas quel sens cela peut avoir. Pourriez-vous nous l'expliquer, s'il vous plaît? Si l'on a deux enregistrements avec des clés différentes, la logique relationnelle veut justement que les lignes correspondent à des données différentes. Avoir 2 lignes de même données sauf la clé autogénérée, c'est ce que l'on cherche normalement à éviter.

gleu, il me semble aussi que s'il existe un index sur (A,B), il ne sert à rien de créer un index sur A. Or c'est ce que tu proposes : n'es-tu donc pas d'accord avec Cédric? pourquoi?
(bon, si c'est trop long ou hors sujet, il faudra peut-être reporter sur une autre discussion)

A mon avis, votre solution (tout mettre sur la même ligne) est idéale... dans un fichier texte. Dans une base de données relationnelles, certainement pas... En fait, je suis tout à fait d'accord avec gleu.
Vous faites aussi une erreur en supposant que les données sont triées dans la table. Ce n'est pas comme cela que ça fonctionne dans une base de données. Les index sont disposés en général suivant un arbre balancé. Les données... euh je ne suis pas assez calée pour expliquer comment c'est dans PostgreSQL, mais ce qu'il faut retenir, c'est qu'on s'en moque éperdument (en tant que développeur, je veux dire, moi ce qui m'intéresse c'est que cela fonctionne   ). Donc ajouter des données n'est pas un problème, ce n'est pas comme dans un beau fichier trié (où là c'est vite le bazar).
Donc (tant pis si je me répète), écoutez gleu, il a raison Cela ne veut pas dire que vous n'aurez pas de souci, mais c'est sans doute la meilleure solution. Et puis 50 millions de lignes, de nos jours, c'est presque courant...

La technique des métadonnées fonctionne, mais pas sur de gros volumes de données. Pour stocker quelques paramètres d'une application (100-1000 lignes peut-être), c'est parfait. Pour les traitements métier d'une application importante, c'est très fortement déconseillé (vu des applications complètement inutilisables à cause de cela).
Après, c'est vous qui voyez en fonction de vos besoins, et de vos contraintes.
La cause de cela, à mon avis, c'est qu'on peut difficilement concilier flexibilité extrème du modèle de données (laisser l'utilisateur ajouter des colonnes au besoin...), performances, robustesse, facilité de développement (utiliser une base de données pour éviter d'écrire votre système de stockage à la main). Il faut savoir quels paramètres privilégier, et dans le cas de l'utilisation d'un SGBDR, on a déjà la robustesse, la facilité de développement.
Bon courage.

(on peut peut-être en rester là sur le hors sujet, non?)