EDIT: Je laisse la réponse acceptée telle quelle, mais veuillez noter que la modification ci-dessous, suggérée par a_horse_with_no_name, est la méthode recommandée pour créer une table temporaire à l'aide de VALUES.
Si vous souhaitez simplement sélectionner certaines valeurs plutôt que de simplement créer un tableau et y insérer des éléments, vous pouvez procéder de la manière suivante:
WITH vals (k,v) AS (VALUES (0,-9999), (1, 100))
SELECT * FROM vals;
Pour créer une table temporaire de la même manière, utilisez:
WITH vals (k,v) AS (VALUES (0,-9999), (1, 100))
SELECT * INTO temporary table temp_table FROM vals;
EDIT: Comme indiqué par a_horse_with_no_name, la documentation indique que CREATE TABLE AS...
son fonctionnement est similaire à celui-ci SELECT INTO ...
, mais que le premier est un sur-ensemble de ce dernier et SELECT INTO
est utilisé dans plpgslq pour attribuer une valeur à une variable temporaire - il échouera donc dans ce cas. Par conséquent, bien que les exemples ci-dessus soient valides pour le SQL pur, le CREATE TABLE
formulaire doit être privilégié.
CREATE TEMP TABLE temp_table AS
WITH t (k, v) AS (
VALUES
(0::int,-99999::numeric),
(1::int,100::numeric)
)
SELECT * FROM t;
Remarque, également à partir des commentaires de a_horse_with_no_name et de la question initiale du PO, cela inclut une conversion vers les types de données appropriés dans la liste de valeurs et utilise une instruction CTE (WITH).
En outre, comme indiqué dans la réponse d'Evan Carrol, une requête CTE est une barrière d'optimisation , c'est-à-dire que le CTE est toujours matérialisé. Il existe de nombreuses bonnes raisons d'utiliser des CTE, mais si elles ne sont pas utilisées avec précaution, les performances peuvent être sérieusement compromises. Cependant, dans de nombreux cas, la barrière d'optimisation peut réellement améliorer les performances. Il faut donc en prendre conscience, et non pas l'aveugler.