Nie mogę znaleźć dokumentacji opisującej prawidłowe formaty nazwy schematu PostgreSQL. Wiem, że nazwa schematu nie może:
- zacznij od liczby
- mieć spacje
- zacząć od
pg_
Co jeszcze? Gdzie powinienem szukać
Nie mogę znaleźć dokumentacji opisującej prawidłowe formaty nazwy schematu PostgreSQL. Wiem, że nazwa schematu nie może:
pg_
Co jeszcze? Gdzie powinienem szukać
Odpowiedzi:
Według dokładnej dokumentacji , myślę, że to może być to, czego szukasz.
Identyfikatory SQL i słowa kluczowe muszą zaczynać się od litery (az, ale także litery ze znakami diakrytycznymi i literami niełacińskimi) lub podkreślenia (_). Kolejnymi znakami w identyfikatorze lub słowie kluczowym mogą być litery, znaki podkreślenia, cyfry (0–9) lub znaki dolara ($). Pamiętaj, że znaki dolara nie są dozwolone w identyfikatorach zgodnie z literą standardu SQL, więc ich użycie może spowodować, że aplikacje będą mniej przenośne ...
pg_
podkreślenia do tego łącza, jak Nathan C wspomniano .
Zgodnie z dokumentacją nie może również zaczynać, pg_
ponieważ jest zarezerwowana. Poza tym wygląda dość swobodnie.
this-is schema
a nadal byłby to niepoprawna nazwa schematu.
Prawidłowa odpowiedź to ta dostarczona przez gsiems. Chciałbym jednak zauważyć, że PostgreSQL ma zasady dotyczące cytowanych identyfikatorów, o których warto pamiętać. „Cytowane identyfikatory mogą zawierać dowolny znak, z wyjątkiem znaku z kodem zero. (Aby dołączyć podwójny cudzysłów, napisz dwa podwójne cudzysłowy.)” ... Istnieją również pewne ograniczenia dotyczące przypadków, które możesz chcieć zobaczyć.
Jeśli więc chcesz podać swoje identyfikatory, możesz użyć dowolnego znaku (z wyjątkiem \ 0). Ale jeśli nie cytujesz swoich identyfikatorów, musisz przestrzegać zasad przedstawionych na tej stronie.
Chciałem zwrócić na to uwagę głównie dlatego, że wcześniej mnie ugryzł, zwłaszcza zasady dotyczące wielkości liter w niecytowanych identyfikatorach (a nazwy schematów liczą się jako identyfikatory).
AKTUALIZACJA:
Jako przykład (nie dotyczy to w szczególności identyfikatorów schematów, ale ma również do nich zastosowanie):
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
To może być oczekiwane zachowanie dla tych, którzy mają doświadczenie z PostgreSQL (i być może standardami SQL), ale ktoś, kto jest nowy w PG i pochodzi z punktu widzenia innych serwerów baz danych (na przykład SQL Server lub Oracle), może natknąć się na to zachowanie i zastanawiam się, dlaczego brakuje właśnie utworzonej tabeli.
Być może niektóre podręczniki zalecają, aby nie używać cytowanych identyfikatorów, ale faktem jest, że cytowane identyfikatory są dostępne do użycia i mogą być używane, a ponadto wiele pakietów sprawia, że polityką jest zawsze używanie identyfikatorów cytowanych podczas tworzenia i uzyskiwania dostępu do relacji, które nie są całkowicie małe litery, np. PGAdmin III.
Na przykład jest to skrypt wygenerowany przez PGAdmin III podczas tworzenia tabeli za pomocą interfejsu użytkownika:
CREATE TABLE public."TBLUSER"
(
username text
)
WITH (
OIDS = FALSE
)
;
Dlatego jedynym sposobem, w jaki użytkownik może uzyskać dostęp do tej tabeli w zapytaniu, jest odwołanie się do jej cytowanego identyfikatora, tj "TBLUSER"
. Próba uzyskania dostępu do tej tabeli w zapytaniu z niecytowanym identyfikatorem spowoduje, że nie uda się zlokalizować relacji, tj TBLUSER
.