Quels sont les formats valides d'un nom de schéma PostgreSQL?

Je n'arrive pas à trouver de documentation décrivant les formats valides d'un nom de schéma PostgreSQL. Je sais qu'un nom de schéma ne peut pas:

• commencer par un nombre
• avoir des espaces
• Commencer avec pg_

Quoi d'autre? Où dois-je chercher?

D'après la belle documentation , je pense que c'est peut-être ce que vous recherchez.

Les identifiants SQL et les mots clés doivent commencer par une lettre (az, mais aussi des lettres avec signes diacritiques et lettres non latines) ou un trait de soulignement (_). Les caractères suivants dans un identifiant ou un mot clé peuvent être des lettres, des traits de soulignement, des chiffres (0-9) ou des signes dollar ($). Notez que les signes dollar ne sont pas autorisés dans les identifiants conformément à la lettre de la norme SQL, leur utilisation peut donc rendre les applications moins portables ...

Selon la documentation , il ne peut pas non plus commencer pg_car il est réservé. En dehors de cela, il semble assez libre.

La bonne réponse est celle fournie par gsiems. Cependant, je tiens à souligner que PostgreSQL a des règles sur les identificateurs entre guillemets que vous pourriez garder à l'esprit. "Les identifiants entre guillemets peuvent contenir n'importe quel caractère, à l'exception du caractère avec le code zéro. (Pour inclure un guillemet double, écrivez deux guillemets doubles)." ... Il existe également des restrictions sur la casse que vous voudrez peut-être regarder.

Donc, si vous allez citer vos identifiants, vous pouvez utiliser n'importe quel caractère de votre choix (à l'exception de \ 0). Mais si vous ne citez pas vos identifiants, vous devez suivre les règles décrites sur cette page.

Je voulais le souligner principalement parce que cela m'a mordu avant, en particulier les règles concernant la casse dans les identifiants non cités (et les noms de schéma comptent comme identifiants).

MISE À JOUR:

À titre d'exemple (non spécifiquement applicable aux identificateurs de schéma, mais également applicable à eux):

    DROP TABLE "tbluser"; -- assuming it exists
    DROP TABLE "TBLUSER"; -- assuming it exists; incidentally, they are two different tables
    CREATE TABLE "TBLUSER" ( username text ); 
    INSERT INTO "TBLUSER" VALUES ( 'joe' ); 
    SELECT * FROM TBLUSER; -- this returns an error that the tbluser relation does not exist
    SELECT * FROM "TBLUSER"; -- works fine

Cela pourrait être un comportement attendu pour ceux qui sont expérimentés avec PostgreSQL (et peut-être les normes SQL), mais quelqu'un qui est nouveau sur PG et qui vient du point de vue d'autres serveurs de base de données (SQL Server ou Oracle par exemple) peut tomber sur ce comportement et me demande pourquoi la table qu'ils viennent de créer manque.

Certains manuels déconseillent peut-être d'utiliser des identificateurs entre guillemets, mais le fait est que les identificateurs entre guillemets sont disponibles et peuvent être utilisés et, en outre, de nombreux packages en font une politique de toujours utiliser des identificateurs entre guillemets lors de la création et de l'accès à des relations qui ne sont pas entièrement en minuscules, par exemple, PGAdmin III.

Par exemple, il s'agit du script généré par PGAdmin III lors de la création d'une table via l'interface utilisateur:

    CREATE TABLE public."TBLUSER"
    (
      username text
    ) 
    WITH (
      OIDS = FALSE
    )
    ;

Par conséquent, la seule façon dont un utilisateur peut accéder à cette table dans une requête est en se référant à son identifiant cité, c'est-à-dire "TBLUSER". Essayer d'accéder à cette table dans une requête avec un identifiant non cité entraînera l'échec de la localisation de la relation, c'est-à-dire TBLUSER.