Använd Datautforskaren

Ett klusters flik Datautforskare arbetar mot klustrets databas som databasens ägare — användaren i anslutningssträngen. Utöver det den användaren får göra kontrolleras varje sats mot dina egna behörigheter innan den körs.

Vem som får använda den

Fliken kräver rollen Database Explorer på klustret, dess resursgrupp eller dess boundary. Ingen annan inbyggd roll innehåller den — varken Owner eller Platform Owner — så den tilldelas alltid uttryckligen; se Database Explorer och Tilldela en roll. Utan den säger fliken att du saknar behörighet.

Database Explorer omfattar att läsa och ändra rader, köra frågor som läser eller ändrar data och att skapa och ändra objekt. Satserna DROP och TRUNCATE ingår inte: de kräver postgrescluster/schemaDrop, som ingen inbyggd roll har. Att hålla inne den skyddar inte datan mot den som har rollen — se Vad som kontrolleras innan en sats körs. Lägg den i en anpassad roll och tilldela den, eller begär den rollen för några timmar — se Anpassade roller och Just-in-time-åtkomst. Alla slags satser och behörigheten var och en kräver finns i Behörigheter.

Fliken är inte tillgänglig när klustret är stoppat eller saknar en instans som är klar.

Bläddra i och redigera rader

1. Öppna fliken Datautforskare. Trädet till vänster listar schemana, deras tabeller och vyer, och varje tabells kolumner.
2. Välj en tabell. Browse visar dess rader, 100 åt gången, med Prev, Next och Refresh, och en uppskattning av antalet rader.
3. För att ändra data redigerar du en cell, lägger till en rad med Row eller markerar rader för borttagning. Ändringarna hålls kvar tills du skickar dem; en ändrad cell visar sitt tidigare värde.
4. Välj Submit, som räknar ändringarna, eller Discard all. De nya raderna tillämpas först, sedan de ändrade raderna, sedan borttagningarna, varje grupp i en transaktion; en grupp som misslyckas stoppar dem som kommer efter och ligger kvar.

Redigering kräver en tabell vars primärnyckel består av exakt en kolumn. För en tabell med en sammansatt nyckel ändrar du rader under Query.

Kör SQL

1. Öppna Query. Tabellen som är vald i trädet visas ovanför redigeraren.
2. Skriv en eller flera satser.
3. Välj något av:
   • Dry run — kör satserna i en transaktion som rullas tillbaka och visar vad som skulle hända: resultaten, de påverkade raderna och, för en borttagning, alla objekt som skulle följa med.
   • Run — kör satserna och genomför dem.
4. För satser som skapar, ändrar eller tar bort objekt avvisas Run tills en provkörning har gått igenom: välj Dry run, kontrollera resultatet och sedan Commit DDL changes. Genomförandet måste komma inom två minuter, från dig, med exakt samma SQL; ändrad SQL kräver en ny provkörning.

Resultatet visar varje sats slag, behörigheterna den krävde och de du saknar. Avvisade satser märks Refused — structurally not allowed.; satser du saknar behörighet för, Denied — missing permissions or guard. — med de åtgärder som skulle kunna ges via just-in-time-åtkomst.

stsh pg query orders-db "select count(*) from orders"
stsh pg query orders-db "alter table orders add column note text" --dry-run
stsh pg schemas orders-db
stsh pg rows orders-db public orders --page-size 20

stsh pg query gör först en provkörning och genomför bara om den går igenom; --dry-run stannar efter den.

Vad som kontrolleras innan en sats körs

Innan något körs tolkar plattformen satserna och klassar var och en:

• En sats som aldrig tillåts — transaktionsstyrning, roller och rättigheter, tillägg, ALTER SYSTEM och de andra som listas under Avvisade satser — gör att hela omgången avvisas.
• Varje annan sats kräver behörigheterna för sitt slag. Saknas någon körs inget av satserna, och resultatet listar alla som saknas.

Vissa satser tillåts med en varning bredvid: UPDATE eller DELETE utan WHERE, DROP (med eller utan CASCADE), TRUNCATE, att ta bort en kolumn, en begränsning eller NOT NULL, att byta ägare, CREATE INDEX utan CONCURRENTLY, och en omgång som blandar borttagningar med andra satser.

Se upp

Kontrollerna gäller de satser du skickar, inte det som de satserna i sin tur kör. En funktion eller trigger som skapas här kör sin kropp som databasens ägare, och satserna i den — DROP och TRUNCATE inräknade — kontrolleras inte. Den som får skapa funktioner (schemaWrite) och köra satser (queryExecute), vilket rollen Database Explorer innehåller, kan därför göra allt som ägaren kan. Data kan också tas bort utan schemaDrop: ALTER TABLE … DROP COLUMN kräver bara schemaWrite, och DELETE utan WHERE bara queryExecuteWrite. Behandla rollen Database Explorer som full åtkomst till databasens data, och ha säkerhetskopiering på för data du inte får förlora.

Gränser

• Hela omgången körs i en transaktion; en omgång med bara läsningar körs skrivskyddat.
• En sats får köra i 30 sekunder och vänta 5 sekunder på ett lås. Genom API:et kan en begäran be om upp till 5 minuter.
• Högst 5 000 rader returneras per omgång, om inte en begäran genom API:et ber om fler; resultatet säger när det kapades.
• En grupp radändringar rymmer högst 500 rader.

Granskningsspåret

Varje omgång — från Query, formulären och Browse — registreras med SQL:en, vem som skickade den, utfallet och, när den kördes, hur lång tid den tog och hur många rader den berörde, provkörningar och avvisade omgångar inräknade. Att lista schematrädet registreras inte. Ändringar som genomförs från Query eller formulären syns också i klustrets Aktivitet, som Editor: … med satsens slag och tabellen; radändringar som skickas på Browse gör det inte.