Comment effectuer une requête de sélection dans un bloc DO?
Je veux le port ci-dessous le code SQL à partir de MS SQL-Serveur PostgreSQL.
DECLARE @iStartYear integer
DECLARE @iStartMonth integer
DECLARE @iEndYear integer
DECLARE @iEndMonth integer
SET @iStartYear = 2012
SET @iStartMonth = 4
SET @iEndYear = 2016
SET @iEndMonth = 1
;WITH CTE
AS
(
SELECT
--@iStartYear AS TheStartYear
@iStartMonth AS TheRunningMonth
,@iStartYear AS TheYear
,@iStartMonth AS TheMonth
UNION ALL
SELECT
--CTE.TheStartYear AS TheStartYear
--@iStartYear AS TheStartYear
CTE.TheRunningMonth + 1 AS TheRunningMonth
--,CTE.TheStartYear + (CTE.TheRunningMonth /12) AS TheYear
,@iStartYear + (CTE.TheRunningMonth / 12) AS TheYear
,(CTE.TheMonth + 1 -1) % 12 + 1 AS TheMonth
FROM CTE
WHERE (1=1)
AND
(
CASE
--WHEN (CTE.TheStartYear + (CTE.TheRunningMonth /12) ) < @iEndYear
WHEN (@iStartYear + (CTE.TheRunningMonth / 12) ) < @iEndYear
THEN 1
--WHEN (CTE.TheStartYear + (CTE.TheRunningMonth /12) ) = @iEndYear
WHEN (@iStartYear + (CTE.TheRunningMonth / 12) ) = @iEndYear
THEN
CASE
WHEN ( (CTE.TheMonth + 1 -1) % 12 + 1 ) <= @iEndMonth
THEN 1
ELSE 0
END
ELSE 0
END = 1
)
)
SELECT * FROM CTE
C'est ce que j'ai jusqu'à présent.
DO $$
DECLARE r record;
DECLARE i integer;
DECLARE __iStartYear integer;
DECLARE __iStartMonth integer;
DECLARE __iEndYear integer;
DECLARE __iEndMonth integer;
DECLARE __mytext character varying(200);
BEGIN
i:= 5;
--RAISE NOTICE 'test'
--RAISE NOTICE 'test1' || 'test2';
__mytext := 'Test message';
--RAISE NOTICE __mytext;
RAISE NOTICE '%', __mytext;
RAISE NOTICE '% %', 'arg1', 'arg2';
--SQL Standard: "CAST( value AS text )" [or varchar]
--PostgreSQL short-hand: "value::text"
__mytext := 'Test ' || i::text;
RAISE NOTICE '%', __mytext;
__mytext := 'mynumber: ' || CAST(i as varchar(33)) || '%';
RAISE NOTICE '%', __mytext;
__iStartYear := 2012;
__iStartMonth := 4;
__iEndYear := 2016;
__iEndMonth := 1;
--PERFORM 'abc';
SELECT 'abc';
-- SELECT __iStartMonth AS TheRunningMonth;
-- RAISE NOTICE 'The raise_test() function began.' + CAST( i AS text ) ;
-- FOR r IN SELECT table_schema, table_name FROM information_schema.tables WHERE table_type = 'VIEW' AND table_schema = 'public'
-- LOOP
-- EXECUTE 'GRANT ALL ON ' || quote_ident(r.table_schema) || '.' || quote_ident(r.table_name) || ' TO webuser';
--END LOOP;
END$$;
Comme vous pouvez le voir, j'ai eu quelques problèmes lorsque l'on veut "imprimer" avec l'augmentation de l'avis de la fonctionnalité. Mais j'ai réussi à résoudre qu'avec Google.
À partir de l'expérience précédente, je peux dire que la syntaxe Postgresql avec CTE est de manière similaire, je n'ai qu'à ajouter un récursif avant la CTE, de sorte que le seul vrai problème c'est que je dois définir quelques variables, pour lesquelles j'ai besoin d'un faire bloc.
De cette résultats de la simple question que j'ai:
Comment puis-je exécuter une requête de sélection en bloc?
Je veux voir les résultats dans les données de sortie de l'onglet " pgAdmin3.
Et je ne veux pas créer une fonction.
source d'informationauteur Stefan Steiger
Vous devez vous connecter pour publier un commentaire.
DO
de commande vs fonctions PL/pgSQLLa
commande ne retourne pas les lignes. Vous pouvez envoyer
NOTICES
ouAUGMENTER
autres messages (avec le langage plpgsql) ou vous pouvez écrire à un (temporaire) de la table et, plus tard,SELECT
pour contourner ce problème.Mais vraiment, vous devriez créer un (plpgsql) fonction la place, où vous pouvez définir un type de retour avec le
RENVOIE
de la clause ou/
INOUT
paramètres et de retour de la fonction de diverses manières.Si vous ne voulez pas que la fonction soit enregistrée et visible pour les autres connexions, envisager un "temporaire" de la fonction, qui est d'un sans-papiers, mais bien établie fonctionnalité:
generate_series()
de problème à portée de mainPour le problème en main, vous ne semblez pas besoin tout de cette. Utilisez cette simple requête à la place:
C'est tout.
Ce n'est pas trop hors-sujet (à mon humble avis), et peut être utile ...
Je suis tombé sur cette question récemment où je nécessaire à l'exécution d'un certain nombre de déclarations dans une transaction et le retour de certains (très peu) de données qui indiquent à un script PHP comment l'opération a été traitée (enregistrements affectés et aucun code d'erreur personnalisée).
Coller à la relance de l'AVIS et de l'AUGMENTER [EXCEPTION] paradigme, j'ai trouvé qu'il est préférable de retourner une chaîne JSON dans l'AVIS/l'EXCEPTION d'être renvoyé. De cette façon, tous les PHP app auriez besoin de faire est d'utiliser pg_last_notice() ou pg_last_error() pour obtenir et décoder la chaîne JSON.
par exemple
ou
Depuis le retour de l'objet JSON nommé "std_response" est en fait une réponse standard pour tous ces types de scripts, c'est vraiment facile d'écrire des tests unitaires depuis la fonction wrapper charge et exécute SQL retournera toujours un "std_response" de l'objet qui peut avoir ses valeurs testées.
Ce paradigme doit uniquement être utilisé si vous revenez de petits morceaux de données dans la relance de message (bien que j'ai vu jusqu'à 96 000 caractères renvoyés de cette façon - pas sûr de ce que la limite est).
Si vous avez besoin de retourner un plus grand ensemble de données, vous devez sauvegarder le résultat dans un tableau, mais au moins vous pouvez toujours utiliser ce paradigme d'isoler précisément les enregistrements qui appartiennent à l'appelé SQL. c'est à dire placer les données dans une table avec un UUID et le retour de l'UUID dans l'AVIS comme suit:
La bonne chose à ce sujet est que depuis qu'il est toujours structuré et décrit le tableau pour sélectionner les données, il peut également être utilisé avec des tests unitaires dans l'application.
(Alternativement, vous pouvez également utiliser Postgresql pour stocker le résultat dans memcache et l'application de ramassage de l'ensemble de données à partir de là, de cette façon, vous n'avez pas à traiter avec les I/O disque pour stocker le résultat de l'application à utiliser pour générer le code HTML, puis jetez immédiatement lorsque le script se termine)