Sto passando lentamente da MSSQL a PostgreSQL.Come modificare la stored procedure di PostgreSQL?
In MSSQL potevo chiamare la modifica della procedura o della funzione già salvata e la shell di amministrazione (SQL Server Management Studio) mi mostrava il testo della procedura, quindi non dovevo memorizzare il suo codice sorgente da qualche parte nel file di testo.
Come fare lo stesso con PostgreSQL nel modo più conveniente? Sto usando pgAdmin III.
phpPgAdmin consente di modificare le stored procedure e modificarle nell'interfaccia. Il commento lasciato sotto la tua domanda su come conservarli esternamente per il controllo della versione è altamente raccomandato.
In pgAdmin si può rendere la vita più facile se si attiva questa opzione:
File -> Opzioni .. -> Query Tool -> [x] Copia SQL dal modulo principale per il dialogo SQL
Quindi, tutto ciò che viene visualizzato nel riquadro SQL verrà copiato in una finestra di Query Tool appena aperta. Quindi, seleziona la funzione nel browser degli oggetti e fai clic sull'icona della lente di ingrandimento nella barra degli strumenti.
Essere consapevoli di un bug aperto nella versione corrente 1.14.2. Per impostazione predefinita, public ha il privilegio EXECUTE sulle funzioni. Puoi REVOKE questo privilegio, che è utile solo per le funzioni SECURITY DEFINER. Ma questo REVOKE manca nelle istruzioni DDL con reverse engineering di pgAdmin (un NULL è stato confuso con un ACL vuoto). Attenzione se si elimina e si ricrea una tale funzione!
È anche un modo conveniente per modificare il codice e testarlo.
1) Estrarre il codice di una funzione SQL richiesta da pgAdmin.
2) Inserire il codice con la funzione in file.sql.
3) Creare un file di shell/bat nella stessa directory con file.sql:
psql -U postgres dbname < file.sql
4) inserire un collegamento per il file di shell/bat in un pannello veloce.
5) Modificare il file con l'editor di testo preferito e premere il collegamento per aggiornare la funzione.
In generale trovo che il tuo contributo sia utile, ma in questo caso specifico il tuo suggerimento è esattamente quello che paul * NON * voleva fare: "quindi non dovevo memorizzare il suo codice sorgente da qualche parte nel file di testo" - probabilmente perché pensa che questo approccio è troppo complicato per essere chiamato "conveniente". – ChristophK
fare clic destro sul funzione albero di oggetti (sul lato sinistro) -> Script -> Script CREATE
oppure
Esegui nuova query SQL -> codice copia di "creare o sostituire funzione ..."Ad essa
quindi modificare il copione e non ha dimenticato di eseguirlo
Memorizzazione di stored procedure in un file esterno è altamente raccomandato in ogni caso (idealmente in un sistema di controllo di versione) –
@a_horse_with_no_name:. Io preferisco un diverso Ho un test db cluster per ogni cluster db produttivo (raramente copiato) dove ho sperimentato.Se considerato buono, implemento nel cluster db produttivo.Oltre ai soliti backup eseguo backup frequenti solo dello schema, specialmente prima/Dopo le modifiche allo schema, i repository tradizionali sono di uso limitato per gli schemi di database poiché i dati cambiano costantemente e molte modifiche non possono essere (facilmente) ripristinate. –
@ErwinBrandstetter: il problema con questo approccio è che si perde l'overv Scopri quali modifiche devi applicare per ottenere un database dalla versione x alla versione x + 1. Hai bisogno di un luogo centralizzato in cui ogni cambiamento possa essere tracciato (e idealmente mappato, ad esempio, in un ticket di emissione). Se si dispone di più di un ambiente (sviluppo, test, gestione temporanea, convalida, regressione, preproduzione, produzione) e forse anche più di una versione in produzione (si pensi a paesi diversi) Non vedo come è possibile tenere traccia di tutti cambia senza VCS. –