Hernoem tabellen veilig met seriële primaire-sleutelkolommen

De gegevenstypen smallserial , serial en bigserial zijn geen echte typen, maar slechts een notatiegemak voor het maken van unieke identificatiekolommen

Het pseudo-gegevenstype is opgelost door dit allemaal te doen:

• maak een reeks met de naam tablename_colname_seq

• maak de kolom met het type integer (of int2 / int8 respectievelijk voor smallserial / bigserial )

• maak de kolom NOT NULL DEFAULT nextval('tablename_colname_seq')

• maak de kolom eigenaar van de reeks, zodat deze er automatisch mee wordt verwijderd

Het systeem doet niet weet of je dit allemaal met de hand hebt gedaan of met het pseudo-gegevenstype serial . pgAdmin controleert de vermelde functies en als aan alle is voldaan, wordt het reverse-engineered DDL-script vereenvoudigd met de overeenkomende serial type. Als aan een van de kenmerken niet wordt voldaan, vindt deze vereenvoudiging niet plaats. Dat is iets wat pgAdmin doet. Voor de onderliggende catalogustabellen is het allemaal hetzelfde. Er is geen serial typ als zodanig.

Er is geen manier om automatisch de naam van sequenties in eigendom te wijzigen. U kunt uitvoeren:

ALTER SEQUENCE ... RENAME TO ...

zoals jij deed. Het systeem zelf geeft niet om de naam . De kolom DEFAULT slaat een OID op ('foo_pkey_seq'::regclass ), kunt u de naam van de reeks wijzigen zonder die te verbreken - de OID blijft hetzelfde. Hetzelfde geldt voor externe sleutels en soortgelijke verwijzingen in de database.

De impliciete index voor de primaire sleutel is gebonden aan de naam van de PK-beperking, die niet wijzigen als u de naam van de tabel wijzigt. In Postgres 9.2 of later kunt u

ALTER TABLE ... RENAME CONSTRAINT ..

om dat ook recht te zetten.

Er kunnen ook indexen worden genoemd die verwijzen naar de tabelnaam. Vergelijkbare procedure:

ALTER INDEX .. RENAME TO  ..

U kunt allerlei informele verwijzingen hebben naar de tabelnaam. Het systeem kan de naam van objecten die u maar wilt, niet met geweld hernoemen. En het maakt niet uit.

Natuurlijk wil je de SQL-code die naar die namen verwijst niet ongeldig maken. Het is duidelijk dat u de namen niet wilt wijzigen terwijl de toepassingslogica ernaar verwijst. Normaal gesproken zou dit geen probleem zijn voor namen van indexen, sequenties of beperkingen, aangezien daar normaal gesproken niet naar wordt verwezen met een naam.

Postgres verwerft ook een slot op objecten voordat ze worden hernoemd. Dus als er gelijktijdige transacties . zijn open die enige vorm van vergrendeling hebben op objecten in kwestie, uw RENAME bewerking is vastgelopen totdat die transacties worden vastgelegd of teruggedraaid.

Systeemcatalogi en OID's

Het databaseschema wordt opgeslagen in tabellen van de systeemcatalogus in het systeemschema pg_catalog . Alle details in de handleiding hier. Als je niet precies weet wat je doet, zou je helemaal niet met die tabellen moeten rommelen . Eén verkeerde beweging en je kunt je database breken. Gebruik de DDL-opdrachten die Postgres biedt.

Voor enkele van de belangrijkste tabellen biedt Postgres objectidentificatietypen en typecasts om de naam voor de OID snel te krijgen en vice versa. Vind ik leuk:

SELECT 'foo_pkey_seq'::regclass

Als de schemanaam in het search_path . staat en de tabelnaam is uniek, dat geeft je hetzelfde als:

SELECT oid FROM pg_class WHERE relname = 'foo_pkey_seq';

De primaire sleutel van de meeste catalogustabellen is oid en intern gebruiken de meeste referenties OID's.