Discussion :

[MaximeCh]

Postgres se défait, tout en continuant de les supporter, de cet partie obsolète du standard avec le type text.
https://www.postgresql.org/docs/12/d...character.html

L'encodage SQL_ASCII est très proche du ASCII_FULL non?
https://www.postgresql.org/docs/12/multibyte.html

[SQLpro]

Postgres se défait, tout en continuant de les supporter, de cet partie obsolète du standard avec le type text.
https://www.postgresql.org/docs/12/d...character.html

Le type text n'existe pas dans la norme SQL…. mais comme le dit la doc de PG, beaucoup de SGBDR avaient un type "text" (notamment Sybase ASE/ASA et SQL Server...). C'est aujourd'hui et depuis la version 2005 de SQL Server, tout à fait obsolète.

L'encodage SQL_ASCII est très proche du ASCII_FULL non?
https://www.postgresql.org/docs/12/multibyte.html

À priori non, car les normes de jeu de caractères les plus proches de cela, visées par le § 4.2.4 de la norme SQL seraient :
"

SQL_CHARACTER specifies the name of a character repertoire that consists of the 88 <SQL
language character>s as specified in Subclause 5.1, ‘‘<SQL terminal character>’’. It consists
of the 52 uppercase and lowercase simple latin characters, 10 digits, and 26 <SQL special charcaters>…

[…]

LATIN1 specifies the name of a character repertoire that consists of the 191 graphic characters
defined in ISO 8859-1.

[…]

"

J'ai pas vu d'encodage avec seulement 128 codes de caractères…

A +

[MaximeCh]

Ce que je voulais dire c'est que la partie national n'a plus vraiment lieu d'être, et varchar est plus fastidieux que text.
La plupart des gens postgres que j'ai lu, Tom Lane, Andres Freund, Dimitri Fontaine, Adrien Nayrat... n'utilisent plus que deux types : char(n) pour du fixe, et text pour le reste.

[esperanto]

NCHAR et CHAR sont des synonymes de NATIONAL CHARACTER et CHARACTER, de même que NVARCHAR et VARCHAR sont des synonymes de NATIONAL CHARACTER VARYING et CHARACTER VARYING. Tous les SGBDR à ma connaissance les acceptent !

Oui mais NVARCHAR n'est pas dans la norme, c'est juste que tous les SGBD ont choisi ce nom.

La définition des jeux de caractères est libre dans les limites suivantes (extrait de la norme SQL Foundation § 4.2.4) :

OK en effet c'est mieux comme ça (le message précédent laissait l'impression que c'est la norme qui imposait que CHAR soit en ASCII par défaut): le choix de CHAR en 8 bits et NCHAR en 16 bits est un choix de SQL Server, pas de la norme.

- ISO8BIT (or ASCII_FULL) specifies the name of a character repertoire that consists of all 255 characters, each consisting of exactly 8 bits, as specified in ISO 4873 and ISO 8859-1,

OK, dans ce cas c'est juste le nom ASCII_FULL qui est inapproprié parce que ASCII (en dehors de la norme SQL), c'est un encodage sur 7 bits. En fait ISO8BIT est plus proche de ISO-8859-1.

— UTF16 and ISO10646 specify the name of a character repertoire that consists of every character represented by The Unicode Standard Version 2.0 and by ISO/IEC 10646 UTF-16, where each character is encoded using the UTF-16 encoding, occupying either 1 (one) or 2 octets.

Là j'avoue être un peu surpris parce que normalement UTF-16, ce ne sont pas 1 ou 2 octets mais 1 ou deux seizets, ou groupes de 16 bits. Soit plutôt 2 ou 4 octets.
Quant à ISO 10646, c'est la bijection entre un caractère et un nombre, indépendamment de la représentation de ces nombres en mémoire (ces représentations étant les fameux UTF-n ou UCS-n)

Sérieux, il fumait quoi l'auteur de la norme SQL quand il a rédigé la section 4.2.4?

SQL Server est strictement conforme à l'ISO8BIT

Mais est-elle strictement limitée à ISO8BIT (donc à ISO-8859-1) ou à Windows-1252 (qui contient quelques caractères en plus)? Ou alors ASCII_FULL signifie qu'on supporte les 256 valeurs mais que ce qui est au delà des 7 bits est considéré uniquement comme un octet sans signification? Le fait que j'ai pu écrire un é (sur 1 caractère) et plus tard j'ai essayé avec € (qui n'est pas dans ISO-8859-1 mais qui est dans Windows-1252) me laisse penser que c'est plutôt Windows-1252...

[SQLpro]

Ce que je voulais dire c'est que la partie national n'a plus vraiment lieu d'être, et varchar est plus fastidieux que text.
La plupart des gens postgres que j'ai lu, Tom Lane, Andres Freund, Dimitri Fontaine, Adrien Nayrat... n'utilisent plus que deux types : char(n) pour du fixe, et text pour le reste.

C'est stupide d'utiliser le type texte en lieu et place d'un varchar correctement dimensionné. En effet dans certains algorithmes il faut aligner les chaines de caractères en les taillants de même longueur. Sans précision d'une longueur maximale, l'algorithme est plus couteux.
Pour information SQL Server dans ce cas avec du VARCHAR(n) prend n/2 avec une zone de débordement histoire de ne pas avoir une empreinte mémoire trop importante !

+

[esperanto]

Ce que je voulais dire c'est que la partie national n'a plus vraiment lieu d'être, et varchar est plus fastidieux que text.

Puisque tu cites la doc de PostgreSQL dans le message précédent, j'attire votre attention à tous les deux sur la remarque placée en vert au milieu: PostgreSQL a fait le choix de tout miser sur le type TEXT et ne supporte les autres que pour être compatible avec la norme.
Je crois même me souvenir d'avoir lu ailleurs dans la doc, mais je ne me souviens pas où, qu'ils recommandaient de ne jamais utiliser VARCHAR ou CHAR et que si vous avez vraiment une contrainte de taille pour une colonne donnée, d'utiliser un DOMAIN à la place.
Bien sûr ils précisent bien que c'est vrai pour une base PostgreSQL et pas ailleurs.

Je reconnais que ce n'est peut-être pas le choix que j'aurais fait. Par contre j'en tiens compte quand je conçois un schéma pour Postgres.

C'est stupide d'utiliser le type texte en lieu et place d'un varchar correctement dimensionné. En effet dans certains algorithmes il faut aligner les chaines de caractères en les taillants de même longueur. Sans précision d'une longueur maximale, l'algorithme est plus couteux.

Sans préciser quels (types d')algorithmes, on peut conclure n'importe quoi. Et puis Postgres a peut-être implémenté ces algorithmes d'une façon différente où, au contraire une contrainte de longueur peut être un inconvénient.

[alassanediakite]

Salut

Je crois même me souvenir d'avoir lu ailleurs dans la doc, mais je ne me souviens pas où, qu'ils recommandaient de ne jamais utiliser VARCHAR ou CHAR et que si vous avez vraiment une contrainte de taille pour une colonne donnée, d'utiliser un DOMAIN à la place.

C'est ici Don't Do This
J'avoue que certains points m'ont laissé "sans mot".
@+

[MaximeCh]

C'est ici Don't Do This
J'avoue que certains points m'ont laissé "sans mot".

Lesquels?

[alassanediakite]

Salut
BETWEEN, NOT IN et SERIAL.

[RenardSpatial]

J'ai eu la même réaction en les lisant, mais en fait :

- BETWEEN c'est en fait très logique quand on a l'explication, et probablement valable avec d'autres SGBD (à vérifier)
- NOT IN c'est en fait le titre qui est trompeur, c'est NOT IN (select …) qui est à éviter (et là encore avec l'explication ça me choque moins)
- SERIAL me surprends plus, même avec les explications (planquées dans le lien). Mais «*The new syntax conforms to the SQL standard.*».

[SQLpro]

Dans la série comparaisons entre PostGreSQL et SQL Server, le premier d'une longue série d'articles :
https://sqlpro.developpez.com/tutori...ndes-pour-dba/
PostGreSQL vs Microsoft SQL Server - Partie 1 : performances des commandes pour le DBA