L’annexe K de la documentation PostgreSQL indique qu’une table peut contenir jusqu’à 1 600 colonnes.
Il s’agit d’une limite codée en dur, visible dans le code source à l’adresse src/include/access/htup_details.h :
#define MaxTupleAttributeNumber 1664
#define MaxHeapAttributeNumber 1600Vérifions d’abord cette affirmation par quelques tests.
Nous utilisons ici un script bash simple, facile à adapter aux différents tests.
-- Exemple classique
DO $$
DECLARE
i int;
BEGIN
EXECUTE 'DROP TABLE IF EXISTS tint_1601;';
EXECUTE 'CREATE TABLE tint_1601(i_1 int);';
FOR i IN 2..1601 LOOP
EXECUTE format('ALTER TABLE tint_1601 ADD COLUMN i_%s int;', i);
END LOOP;
END $$;Le résultat est le suivant :
NOTICE: table "tint_1600" does not exist, skipping
ERROR: tables can have at most 1600 columns
CONTEXT: SQL statement "ALTER TABLE tint_1600 ADD COLUMN i_1601 int;"
PL/pgSQL function inline_code_block line 8 at EXECUTEJusqu’ici, tout va bien (ou du moins, tout fonctionne comme prévu).
Vous pourriez tenter de remplacer le type int4 par le type int2 pour arriver à créer une table de plus de 1 600 colonnes. Mais cela ne fonctionnera pas plus, car il s’agit d’une limite codée en dur.
Générons une table de 1600 colonnes à partir du script sql précédent :
DO $$
DECLARE
i int;
BEGIN
EXECUTE 'DROP TABLE IF EXISTS tint_1600;';
EXECUTE 'CREATE TABLE tint_1600(i_1 int);';
FOR i IN 2..1600 LOOP
EXECUTE format('ALTER TABLE tint_1600 ADD COLUMN i_%s int;', i);
END LOOP;
END $$;Construisons puis insérons un tuple de 1600 colonnes :
DO $$
DECLARE
s TEXT;
rows_inserted int;
BEGIN
s := format(
'INSERT INTO tint_1600 VALUES (1%s);'
, repeat( ',1' , 1599 )
);
EXECUTE s;
GET DIAGNOSTICS rows_inserted = ROW_COUNT;
RAISE NOTICE 'Rows inserted: %', rows_inserted;
END $$;The output is:
NOTICE: Rows inserted: 1
DOSans surprise, c’est encore un succès.
Continuons à repousser les limites.
On créé maintenant une autre table de 1 600 colonnes, cette fois avec le type de données char(127).
On réutilise notre script bash avec quelques modifications :
-- Create a table with 1,600 columns: 1 x int + 1599 x char(127)
DO $$
DECLARE
i int;
BEGIN
EXECUTE 'DROP TABLE IF EXISTS tint_1600;';
EXECUTE 'CREATE TABLE tint_1600(i_1 int);';
FOR i IN 2..1600 LOOP
EXECUTE format('ALTER TABLE tint_1600 ADD COLUMN c_%s char(127) NOT NULL;', i);
END LOOP;
END $$;
-- Insert a tuple - 1 x int + 1599 x char(127)
DO $$
DECLARE
s TEXT;
BEGIN
s := format(
'INSERT INTO tint_1600 VALUES (1%s);'
, repeat( $q$,'1'::char(127)$q$ , 1599 )
);
EXECUTE s;
END $$;```
Le résultat est :ERROR: row is too big: size 25616, maximum size 8160
Comme on peut le voir, la table comporte effectivement 1 600 colonnes, mais cette fois, le tuple ne peut pas tenir dans une seule page heap, ce qui explique l'erreur « row is too big: size 25616, maximum size 8160 ». Si vous avez fait attention au script, vous avez pu constater que les colonnes sont définies comme `NOT NULL`. Aussi, lors de la création de la table, PostgreSQL aurait pu se rendre compte que l'insertion de données serait impossible. Mais il n'y a pas eu d'alerte.
## Quid des JOINs ?
Pour simplifier, testons avec une jointure automatique :
```sql
SELECT a.*,b.* FROM tint_1600 a, tint_1600 b;
ERROR: target lists can have at most 1664 entriesMaintenant, c’est la clause SELECT de (a.*,b.*) qui a atteint sa propre limite (MaxTupleAttributeNumber = 1664).
Il arrive que vous deviez modifier votre application, et que cela entraîne des modifications de schéma.
La plupart du temps, il s’agit de modifications de tables, comme l’ajout ou la suppression de colonnes.
ADD / DROP COLUMNVoyons ce qui se passe côté SQL lorsque nous ajoutons, puis supprimons, une colonne.
=# CREATE TABLE tadc_1600(i_1 int NOT NULL);
CREATE TABLE
=# ALTER TABLE tadc_1600 ADD COLUMN i_2 int NOT NULL;
ALTER TABLE
=# SELECT attname,attnum,attstorage,attnotnull,attisdropped
FROM pg_attribute
WHERE attrelid=(
SELECT oid
FROM pg_class
WHERE relname='tadc_1600'
)
AND attnum > 0 ORDER BY attnum;
attname | attnum | attstorage | attnotnull | attisdropped
---------+--------+------------+------------+--------------
i_1 | 1 | p | t | f
i_2 | 2 | p | t | f
(2 rows)
=# ALTER TABLE tadc_1600 DROP COLUMN i_2;
ALTER TABLE
=# SELECT attname,attnum,attstorage,attnotnull,attisdropped
FROM pg_attribute
WHERE attrelid=(
SELECT oid
FROM pg_class
WHERE relname='tadc_1600'
)
AND attnum > 0 ORDER BY attnum;
attname | attnum | attstorage | attnotnull | attisdropped
------------------------------+--------+------------+------------+--------------
i_1 | 1 | p | t | f
........pg.dropped.2........ | 2 | p | f | t
(2 rows)Lors de la suppression d’une colonne, cette colonne
On peut se demander s’il existe une limite au nombre d’opérations d’ajout/suppression qui peuvent être exécutées sur une table donnée.
Comme d’habitude, testons :
-- ADD / DROP COLUMN example
DO $$
DECLARE
i int;
BEGIN
EXECUTE 'DROP TABLE IF EXISTS tadc;';
EXECUTE 'CREATE TABLE tadc(i_1 int);';
FOR i IN 2..1601 LOOP
EXECUTE format('ALTER TABLE tadc ADD COLUMN i_%s int;', i);
EXECUTE format('ALTER TABLE tadc DROP COLUMN i_%s;', i);
END LOOP;
END $$;Le résultat est :
ERROR: tables can have at most 1600 columns
CONTEXT: SQL statement "ALTER TABLE tadc ADD COLUMN i_1601 int;"
PL/pgSQL function inline_code_block line 8 at EXECUTEOh oh ! On a atteint la limite des 1 600 ici aussi !
Explorons un peu ce qui se passe :
=# SELECT attname,attnum,attstorage,attnotnull,attisdropped
FROM pg_attribute
WHERE attrelid=(
SELECT oid
FROM pg_class
WHERE relname='tadc'
)
AND attnum > 0 ORDER BY attnum;
attname | attnum | attstorage | attnotnull | attisdropped
---------------------------------+--------+------------+------------+--------------
i_1 | 1 | p | t | f
........pg.dropped.2........ | 2 | p | f | t
........pg.dropped.3........ | 3 | p | f | t
........pg.dropped.4........ | 4 | p | f | t
........pg.dropped.5........ | 5 | p | f | t
........pg.dropped.1599........ | 1599 | p | f | t
........pg.dropped.1600........ | 1600 | p | f | t
(1600 rows)La table tadc comporte 1 600 colonnes. Vous pouvez vous en apercevoir car toutes les modifications sont ajoutées à la table, et son contenu n’est pas réécrit.
Aussi, à ce stade, toute modification supplémentaire visant à ajouter ou supprimer des colonnes sera vouée à l’échec.
Comment faire pour me sortir de cette situation ?
Et non ! La commande VACUUM fonctionne au niveau du tuple, donc même si vous exécutez un VACUUM FULL, la structure de la table ne changera pas.
Il ne s’agit pas d’un problème de tuples morts, mais plutôt d’un problème de catalogue.
Vous devez créer une nouvelle définition de table.
Voici quelques solutions, des plus simples aux plus complexes :
Créer une nouvelle table avec interruption de service
CREATE TABLE LIKE (INCLUDING ALL)COPY) les données de l’ancienne table vers la nouvelleExploiter la réplication logique pour minimiser les interruptions de service
CREATE TABLE LIKE (INCLUDING ALL)CREATE local PUBLICATION/SUBSCRIPTIONVous avez d’autres idées pour résoudre ce problème ? Vous avez trouvé d’autres moyens étranges de déclencher cette erreur liée à la limite codée en dur ? Contactez-nous ! Nous sommes toujours ravis d’échanger sur PostgreSQL.
]]>Les statistiques (au sens large: compteurs de supervision, métriques I/O, et estimations pour le planificateur / optimiseur) sont au cœur à la fois de l’optimisation de performance et des décisions internes de PostgreSQL. Des statistiques transparentes, fiables et manipulables permettent entre autres aux DBAs d’adresser directement l’efficacité de PostgreSQL, et donnent aux «extensions» la possibilité d’améliorer l’expérience utilisateur.
Cela dit, le système historique de statistiques de PostgreSQL n’était pas exempt de frictions: capacité limitée à réinitialiser les statistiques des relations, métriques exprimées dans des unités pas toujours alignées avec les besoins utilisateurs, absence d’API C pour utiliser le moteur de statistiques cumulatives de PostgreSQL. PostgreSQL 18 répond directement à ces préoccupations.
Voici un résumé des améliorations clés.
Bien que les statistiques soient extrêmement utiles, leur collecte peut consommer du temps et des ressources. PostgreSQL 18 introduit un point important: avec l’élargissement du spectre des métriques collectables, la taille maximale de la table de hachage a été augmentée. Gardez cela à l’esprit, surtout si vous concevez des systèmes à grande échelle avec des architectures «un ensemble de tables par client»: on a constaté que la limite de 1 Go pouvait être atteinte avec quelques millions de tables.
Voici les nouvelles fonctionnalités majeures ou les améliorations concernant les statistiques et la supervision.
De manière générale, pg_stat_io rapporte désormais l’activité I/O en octets plutôt qu’en pages, ce qui est plus pratique pour l’analyse. De plus, les statistiques WAL y ont été déplacées depuis pg_stat_wal, offrant ainsi une vue unique et complète.
pg_upgrade est désormais capable de conserver les statistiques de l’optimiseur, supprimant la nécessité de relancer un ANALYZE complet pour obtenir de bons plans de requêtes après une montée de version: une avancée très attendue pour les grandes bases!
Attention toutefois: les statistiques personnalisées ajoutées par une extension ainsi que celles créées avec CREATE STATISTICS ne sont pas conservées.
Vous voudrez sûrement examiner les nouvelles options de vacuumdb (--missing-stats-only) pour n’analyser que ce qui est nécessaire.
Dans la même veine, l’option --[no-]statistics a été ajoutée à pg_dump, pg_dumpall, et pg_restore.
Il est désormais plus simple d’évaluer l’effort de maintenance sur les objets, puisque le temps total passé dans les opérations VACUUM et ANALYZE (y compris
automatiques) est rapporté dans pg_stat_all_tables et ses variantes.
Un nouveau GUC à ne pas oublier: track_cost_delay_timing. Il collecte le temps passé à dormir (suite aux opérations retardées) pour VACUUM et ANALYZE. Très intéressant, mais comme les autres GUC track_io*, il multiplie les appels à l’horloge système, ce qui peut provoquer un impact sévère sur certaines plateformes. Toujours vérifier avec un outil comme pg_test_timing pour s’assurer que votre système peut le supporter!
Plus de questions sur l’activité du checkpointer grâce à pg_stat_checkpointer. Le nouvel attribut num_done indique le nombre de checkpoints terminés. Vous pouvez aussi savoir quel type de buffers a été écrit grâce à slru_written, et buffers_written qui ne concerne désormais que shared_buffers: auparavant, journal et vue n’affichaient pas les mêmes totaux, car un compteur SLRU existait dans un cas mais pas dans l’autre.
Envie d’en savoir plus sur l’I/O traité par un backend (PID) ? Appelez pg_stat_get_backend_io(int) et vous obtiendrez une sortie similaire à la vue pg_stat_io, mais pour ce processus. Pour les stats WAL de ce PID: utilisez pg_stat_get_backend_wal(int).
De nouveaux attributs parallel_workers_to_launch et parallel_workers_launched apparaissent dans pg_stat_database. Le ratio permet de savoir si nous avons assez de slots pour les workers parallèles.
Changements intéressants dans pg_stat_statements: plus de requêtes seront regroupées sous le même identifiant. Par exemple, les
motifs IN (1,2,3, ...) n’utiliseront que la première et la dernière constante. Un changement plus contre-intuitif concerne le nom de table utilisé dans une requête: seul le nom est pris en compte, pas le schéma ni l’OID de relation. Cela permet de suivre les tables supprimées ou recréées, mais cela peut aussi regrouper les stats de tables sans lien ayant simplement le même nom. Pour séparer les stats de tables homonymes, il faudra les aliaser dans les requêtes (FROM my.table mt, other.table ot)…
Enfin, ajouts à pg_backend_memory_contexts avec path (pour récupérer parent/enfant) et type pour distinguer les contextes AllocSet, Generation, Slab et Bump… Et au fait, que sont Slab et Bump ? Pas documentés ; il faut lire les en-têtes des fichiers C ici. Ils existent pour optimiser l’allocation, la réallocation et la réinitialisation mémoire selon les usages attendus. Par exemple, Slab est défini comme un «MemoryContext implementation designed for cases where large numbers of equally-sized objects can be allocated and freed efficiently with minimal memory wastage and fragmentation».
Ah, non, encore une dernière: wal_buffers_full a été ajouté à pg_stat_statements pour permettre un meilleur réglage de wal_buffers.
De meilleures informations apparaissent désormais pour la gestion des conflits en réplication logique grâce à de nouveaux attributs dans pg_stat_subscription_stats. En référence, cet extrait du commit liste les attributs introduits:
confl_insert_exists: nombre de fois où une insertion de ligne a violé une contrainte unique NOT DEFERRABLE.confl_update_origin_differs: nombre de fois où une mise à jour a été faite sur une ligne déjà modifiée par une autre origine.confl_update_exists: nombre de fois où la valeur mise à jour d’une ligne viole une contrainte unique NOT DEFERRABLE.confl_update_missing: nombre de fois où le tuple à mettre à jour est manquant.confl_delete_origin_differs: nombre de fois où une suppression a été effectuée sur une ligne déjà modifiée par une autre origine.confl_delete_missing: nombre de fois où le tuple à supprimer est manquant.Un nouveau jeu de fonctions permet désormais de gérer les statistiques de relations et d’attributs (relpages, avg_width, etc.). Cela offre la possibilité d’exporter, importer et ajuster les stats à volonté, afin de répliquer le comportement du planificateur hors production, de maintenir des stats corrigées, et plus encore.
L’une des évolutions les plus enthousiasmantes est ce que PostgreSQL 18 ouvre aux auteurs d’extensions.
Cette petite ligne au bas de la section E.1.3.9 Modules est celle qui nous intéresse :
Allow extensions to use the server’s cumulative statistics API (Michael Paquier)
Jusqu’ici, la manipulation des statistiques était réservée à l’interne ; désormais, une API officielle et structurée est disponible pour construire (ou envelopper) autour.
Le message de commit est bien rédigé et couvre l’essentiel des nouveautés. Un sous-ensemble des options est détaillé dans la documentation. Cependant, il faut encore plonger dans le code source pour en savoir plus ; en particulier, il vaut la peine de regarder l’extension injection points (fournie avec PostgreSQL) qui utilise cette nouvelle API.
Pour aller plus loin sur la manière dont une extension peut exploiter ces nouvelles capacités, vous pourrez bientôt découvrir PACS (PostgreSQL Advanced Cumulative Statistics) sur Codeberg : mon projet qui propose une bibliothèque de wrappers et des utilitaires autour des nouvelles APIs de statistiques de PostgreSQL 18.
En attendant, la présentation que j’ai donnée à FOSDEM 2025 explore ce sujet plus en détail.
]]>Il était une fois, dans une salle serveur lointaine, entourée de verre blindé et de béton armé, une base PostgreSQL tellement confinée, tellement isolée, qu’elle ne pouvait que rêver du cloud.
Pas de réseau.
Pas d’USB.
Aucun stockage externe accessible en écriture.
Juste un clavier, un écran, et le bourdonnement des filtres à air de qualité industrielle.
Ce n’était pas un simple environnement “air-gapped”. C’était une zone d’exfiltration zéro, avec une sécurité opérationnelle si rigoureuse qu’on aurait cru qu’elle protégeait des secrets d’État — ou pire, un système bancaire des années 80.
Et pourtant, dans cet oubli numérique, une question demeurait :
Comment sauvegarder une base PostgreSQL sans jamais extraire un seul fichier ?
Notre client ne voulait pas juste une sauvegarde. Il en avait besoin. La crainte n’était pas le vol, mais la perte totale : une carte mère qui meurt en silence, enfermant les données à jamais dans sa cage de verre. Et dans ce cas, casser le mur à la masse n’est pas un plan de reprise d’activité très élégant.
Nous avons envisagé toutes les options :
psql ? Beaucoup trop verbeux.Et puis, l’illumination : les QR codes.
Et si on faisait un pg_dump de la base…
…en QR codes…
…affichés à l’écran…
…filmés par une caméra haute fréquence…
…puis reconstitués image par image à l’extérieur ?
C’était absurde. Donc forcément prometteur.
pg_dump : la version pixeliséeL’outil adoré pg_dump de PostgreSQL est modulaire. On l’a donc enrichi d’un nouvel “archiver” : --format=qrcode.
Voici le fonctionnement :
stdout.Pas de macros. Pas de tricherie. Juste des photons et des images.
Une fois la vidéo extraite du cube de verre :
pg_dump.sql complet.Et voilà : la base renaît — entièrement exportée sans transfert numérique.
Rien que de la lumière et des lentilles.
Ce n’est pas juste une anecdote technique — c’est une preuve que la souplesse de PostgreSQL s’étend jusqu’à l’absurde. Les environnements ultra-sécurisés ne sont pas rares : défense, finance, infrastructures critiques… Et quand les outils classiques ne suffisent plus, l’architecture extensible de PostgreSQL permet d’innover, même en milieu extrême.
Chez Data Bene, on vit pour ce genre de défi. Optimiser les plans d’exécution ou imaginer des méthodes d’exfiltration qui ressemblent à de l’espionnage, c’est notre terrain de jeu.
Envie d’essayer ? Écrivez-nous — on adore les sauvegardes bizarres.
Et si jamais vous pensez à utiliser pg_restore en spectacle laser, appelez-nous. On est curieux.
Dans cet épisode nous présentons l’extension open source StatsMgr, récemment publiée, créée pour surveiller et suivre en continu les événements sur PostgreSQL et le système sous-jacent. Voici un aperçu de ce que cet épisode a couvert :
À l’origine, l’idée était de fournir une interface simplifiée pour les métriques, tout en les enrichissant avec une grande variété de types disponibles. Cette fonctionnalité a ensuite été étendue pour résoudre des problèmes tels que :
Cette extension est aussi très bien pour gérer des situations telles que lorsque…
Actuellement, les types de statistiques pris en charge incluent :
Chacun est enregistré auprès d’un gestionnaire qui vous permet de récupérer et de gérer ces statistiques, et est également accompagné de structures de mémoire partagée pour stocker des instantanés historiques.
Certaines des prochaines étapes du projet comprendront l’ajout de statistiques dynamiques telles que pg_stat_user_tables, entre autres.
Il reste encore beaucoup de choses à faire, des améliorations subtiles aux nouvelles fonctionnalités majeures. Il existe donc bien sûr de nombreuses opportunités de contribuer au projet, que vous soyez un nouveau venu ou un développeur PostgreSQL confirmé. Vous souhaitez participer à l’effort ? Consultez CONTRIBUTING.md dans le projet.
Pour une exploration approfondie de StatsMgr et de ses capacités, regardez l’épisode complet ici :
Il y a encore beaucoup à venir sur Postgres Café. Abonnez-vous à la playlist pour découvrir des épisodes qui présentent d’autres outils open source comme pgroll pour les migrations de schémas sans interruption de service, ou Citus Data une extension pour des bases PostgreSQL distribuées et évolutives, et bien plus encore. Restez en contact pour découvrir comment chaque outil peut rendre le travail avec Postgres plus fluide et plus efficace.
]]>Cet article est le résultat d’une revue de code demandée par l’un de nos clients.
Notre client a exécuté la commande pg_dump --schema-only pour nous fournir
les définitions des objets de niveau database ainsi que le code PLpgsql à auditer.
Jusque là, tout allait bien.
J’ai commencé à lire le code et tout d’un coup je fus pris d’un doute, vous savez
le méchant doute qui vous donne l’impression que votre château de cartes va s’écrouler.
Voici la fonction que j’avais sous les yeux:
CREATE FUNCTION xxx( p_id character, p_info character varying )
RETURNS integer
LANGUAGE plpgsql
AS $$
DECLARE
BEGIN
...
INSERT INTO t1
SELECT * FROM t2 WHERE t2.id = p_id;
...
END;
$$
;Peut-être que la première lecture de la fonction ne vous a pas choqué.
Et si je vous disais que la définition de la table t2 ressemble à ce qui suit:
CREATE TABLE t2 (
id VARCHAR(130) NOT NULL
...
PRIMARY KEY (id)
);En pratique t2.id est toujours une chaîne de 130 caractères et il y a 400
millions de tuples dans cette table. Comme vous l’avez déjà probablement compris,
il semble étonnant d’avoir p_id CHARACTER pour manipuler id VARCHAR(130). Pour
mémoire, CHARACTER est l’alias de CHAR(1).
Notre client utilise cette fonction depuis plusieurs années et il n’a pas eu de
problème avec ce code. Néanmoins, notre client m’a dit que la définition de cette
fonction ne correspond pas à ce qu’il a écrit: c’était p_id CHARACTER(130) et
non CHARACTER.
Mais que s’est-il donc passé ? Attaquons la pelotte de laine et voyons si Ariane
nous est d’un grand secours.
CREATE FUNCTION test( c character, d character varying )
RETURNS void
LANGUAGE plpgsql
AS $$
BEGIN
RAISE NOTICE 'c=%, d=%', c,d;
END;
$$;
SELECT test( '123465789', '987654321' );
NOTICE: c=123465789, d=987654321
test
------
(1 row)Voilà un résultat bien intéressant: la chaîne ‘123456789’ n’a pas été réduite à
‘1’ (pas de CAST CHAR(1)). Augmentons le niveau de détails:
EXPLAIN (COSTS OFF,ANALYZE,VERBOSE)
SELECT test( '123465789', '987654321' );
NOTICE: c=123465789, d=987654321
QUERY PLAN
---------------------------------------------------------------------
Result (actual time=0.040..0.041 rows=1 loops=1)
Output: test('123465789'::bpchar, '987654321'::character varying)
Planning Time: 0.023 ms
Execution Time: 0.053 ms
(4 rows)Nous observons un CAST vers bpchar. Pour mémoire, BPCHAR représente une
chaîne pouvant contenir 10 485 760 caractères. Il est aussi un alias de
CHARACTER ce qui explique partiellement le passage de CHARACTER à BPCHAR.
Explorons une autre facette du problème:
CREATE FUNCTION test(c character(4))
RETURNS character(4)
LANGUAGE sql
AS $$
select c;
$$;Nous avons changé le langage de la fonction pour savoir si le comportement observé
est propre à PLpgsql. Les données en entrée et en sortie sont de type CHAR(4).
Comment cela va-t-il se comporter ?
SELECT test('123456789');
test
-----------
123456789
(1 row)
EXPLAIN VERBOSE SELECT test('123456789');
QUERY PLAN
-------------------------------------------
Result (cost=0.00..0.01 rows=1 width=32)
Output: '123456789'::bpchar
(2 rows)La bonne nouvelle (si si) c’est que le comportement observé est le même dans
les deux contextes. En revanche, alors que l’on s’attend à manipuler des données
de type CHAR(4), la fonction manipule des données de taille arbitraire (limitée
à ~10M caractères) !!
Cependant, ne vous précipitez pas dans la mailing list de PostgreSQL pour vous plaindre !
En fait, ce comportement n’est pas un bug. La documentation affirme:
“The full SQL type syntax is allowed for declaring a function’s arguments and return value. However, parenthesized type modifiers (e.g., the precision field for type numeric) are discarded by CREATE FUNCTION. Thus for example CREATE FUNCTION foo (varchar(10)) … is exactly the same as CREATE FUNCTION foo (varchar) …”
Ceci explique que CHARACTER(x) devient CHARACTER transformé (par aliasing)
en BPCHAR qui n’est pas CHAR(1) mais plutôt VARCHAR(10485760). Le
comportement est maintenant complétement expliqué.
Attendez une seconde ! L’intention était de traiter des données CHAR(4) pas
de taille différente.
N’y a-t-il pas de solution ? Non, désolé… (à mois que…)
Plus loin dans la page de la documentation référencée ci-dessus, on peut lire
que argtype et rettype peuvent être de type base, composite, domain
ou même du type d’une table/colonne.
L’astuce est de créer un type composite ou un domain a utiliser en tant que
argtype et/ou rettype.
Voici quelques exemples:
-- Works in simple case trick
SELECT test( '12345789'::char(4) );
-- Domain trick
CREATE DOMAIN c4 AS char(4);
CREATE FUNCTION test(param c4)
RETURNS c4
AS $$
BEGIN
RAISE NOTICE 'param=%', param;
RETURN param;
END;
$$ LANGUAGE plpgsql;
SELECT test( '123456789' );
ERROR: value too long for type character(4)
SELECT test( '123456789'::char(4) );
NOTICE: param=1234
test
------
1234
(1 row)
SELECT test( '123456789'::c4);
NOTICE: param=1234
test
------
1234
(1 row)
SELECT pg_typeof( test( '123456789'::char(4) ) );
NOTICE: param=1234
pg_typeof
-----------
c4
(1 row)Le résultat obtenu devrait vous satisfaire.
Vous n’êtes pas satisfait ?
Je vous propose une dernière astuce.
-- Map a table structure
CREATE TABLE qq ( c char(4));
CREATE FUNCTION test(IN c qq, OUT d qq)
LANGUAGE sql
AS $$
SELECT c;
$$;
SELECT * FROM test(ROW('12345'));
ERROR: value too long for type character(4)
SELECT * from test(ROW('1234'));
c
------
1234Hmm, d’accord mais en quoi est-ce différent de l’utilisation d’un domain ?
-- Easy Type Alteration
ALTER TABLE qq ALTER c TYPE char(5);
SELECT * FROM test( ROW('12345') );
c
-------
12345Essayer de modifier un domain, vous verrez comme c’est simple et pas impactant (…).
L’astuce basée sur la définition de table permet de la flexibilité:
ALTER TABLE qq ADD ee int;
SELECT test( ROW('12345', 4) );
test
----------
(12345,4)
SELECT * FROM test( ROW('12345', 4) );
c | ee
-------+----
12345 | 4Nous espérons que vous avez apprécié cet article et que vous avez appris quelque chose de nouveau et d’intéressant.
]]>