Quais são os formatos válidos de um nome de esquema do PostgreSQL?


14

Não consigo encontrar documentação que descreva os formatos válidos de um nome de esquema do PostgreSQL. Eu sei que um nome de esquema não pode:

  • comece com um número
  • tem espaços
  • começar com pg_

O quê mais? Onde devo procurar?

Respostas:


17

De acordo com a documentação , acho que isso pode ser o que você está procurando.

Identificadores SQL e palavras-chave devem começar com uma letra (az, mas também letras com marcas diacríticas e letras que não sejam latinas) ou um sublinhado (_). Os caracteres subsequentes em um identificador ou palavra-chave podem ser letras, sublinhados, dígitos (0 a 9) ou cifrões ($). Observe que cifrões não são permitidos nos identificadores de acordo com a letra do padrão SQL, portanto, seu uso pode tornar os aplicativos menos portáteis ...


Obrigado. Vou seguir estas instruções e ver se esses são nomes de esquema válidos. Se assim for, então eu vou aceitar isso.

Talvez queira adicionar pg_sublinhado a esse link, como Nathan C mencionou .
Ramon Tayag

5

De acordo com a documentação , também não pode começar pg_como está reservado. Fora isso, parece bastante livre.


Obrigado, vou adicionar isso à lista de quais esquemas não podem ser nomeados. Infelizmente, não é a única regra, aparentemente. Eu poderia nomear this-is schemae ainda seria um nome de esquema inválido.

3
@ Ramon: este é ou é um esquema são nomes de esquema válidos, estritamente falando. Você parece estar confundindo o que é válido com quando deve ser citado .
Daniel Vérité

Sim, você provavelmente está certo. Deixe-me olhar para isso.
Ramon Tayag

3

A resposta correta é a fornecida pelo gsiems. No entanto, quero ressaltar que o PostgreSQL possui regras sobre identificadores citados que você pode ter em mente. "Identificadores entre aspas podem conter qualquer caractere, exceto o caractere com código zero. (Para incluir aspas duplas, escreva duas aspas duplas.)" ... Existem também algumas restrições no caso de você querer examinar.

Portanto, se você quiser citar seus identificadores, poderá usar qualquer caractere que desejar (com exceção de \ 0). Mas se você não está citando seus identificadores, precisa seguir as regras descritas nessa página.

Eu queria salientar isso principalmente porque isso já me incomodou antes, especialmente as regras relativas a maiúsculas e minúsculas nos identificadores não citados (e os nomes dos esquemas contam como identificadores).

ATUALIZAR:

Como exemplo (não aplicável especificamente aos identificadores de esquema, mas igualmente aplicável a eles):

    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

Esse pode ser um comportamento esperado para aqueles que têm experiência com o PostgreSQL (e talvez os padrões SQL), mas alguém que é novo no PG e vindo do ponto de vista de outros servidores de banco de dados (SQL Server ou Oracle, por exemplo) pode se deparar com esse comportamento e pergunto por que a tabela que eles acabaram de criar está ausente.

Talvez alguns manuais não recomendem o uso de identificadores entre aspas, mas o fato é que os identificadores entre aspas estão disponíveis para uso e podem ser usados. Além disso, muitos pacotes definem como política usar sempre identificadores entre aspas ao criar e acessar relações que não são minúsculas, por exemplo, PGAdmin III.

Por exemplo, este é o script gerado pelo PGAdmin III ao criar uma tabela através da interface do usuário:

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

Portanto, a única maneira de um usuário acessar essa tabela em uma consulta é consultando seu identificador entre aspas, ou seja "TBLUSER",. Tentar acessar esta tabela em uma consulta com um identificador não citado resultará em falha na localização da relação, ou seja TBLUSER,.


Comentários não são para discussão prolongada; esta conversa foi movida para o bate-papo .
Paul White 9
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.