2015-10-06 3 views
12

Le variabili di tipo RAW sono immutabili nel codice PL/SQL? Voglio dire, posso alterare il byte specifico della variabile di tipo RAW al posto giusto senza copiare la memoria?Le variabili di tipo RAW sono immutabili nel codice PL/SQL?

Naturalmente abbiamo UTL_RAW pacchetto con alcune routine appropriati per alterare spec byte ma sembra che tutti loro copia variabile di memoria esempio:

UTL_RAW.BIT_ANDUTL_RAW.BIT_ORUTL_RAW.OVERLAY

Anche questa domanda è strettamente legata alla stringa efficace problema di concatenazione Ad esempio, anche le stringhe Java sono immutabili e abbiamo StringBuilder per questa attività. Non ho trovato informazioni chiare nei documenti Oracle su questo. Dopo un po 'di ricerca su google [1], la risposta corrisponde a come: Sì. Le variabili di tipo RAW sono immutabili nel codice PL/SQL così come le stringhe. È proprio vero? Sarebbe meglio avere più spiegazioni e storia di questa domanda.

Riferimenti:

  1. https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:10445025326812#followup-76860752200038
+0

Non sono sicuro di aver compreso lo scopo di questa domanda. È certamente possibile aggiornare le variabili RAW, proprio come qualsiasi altra variabile. La semantica è la stessa. Anche l'eccezione riguardante i parametri NOCOPY si applica allo stesso modo, ma ciò non è applicabile a nessuna delle funzioni in UTL_RAW, per quanto posso vedere. Perché è necessario modificare un bit specifico di una variabile RAW senza copiare la memoria? –

+0

Lo scopo in generale è quello di eliminare il comportamento interno della macchina PL \ SQL. C'è anche un problema pratico di efficienza nel lavorare con le stringhe \ raw's. Otterremo un traffico di memoria elevato se faremo enormi quantità di operazioni su di loro. Ad esempio la concatinazione. Perché questo mi confonde? A causa di Java e di ciò che esiste in StringBuilder. Sembra che abbiamo problemi e soluzioni in Java e in PL \ SQL abbiamo solo un problema. –

+3

Non sei ancora sicuro di quale sia il tuo problema. Se le prestazioni di puro PL/SQL sono un problema, allora usare NOCOPY e/o forse PL/SQL compilato in modo nativo può essere un modo per esplorare. Tuttavia, le variabili di 'RAW' non sono un problema in se stesse; presumibilmente li stai usando per risolvere un problema: qual è il problema che stai cercando di risolvere? –

risposta

5

Non c'è nulla di simile in PL/SQL come alterare una sottoparte specifica della memoria allocata a una variabile. Se è una funzione (come nel caso delle dette routine utl_raw), restituisce sempre una nuova istanza di un valore. Se si tratta di una procedura con un parametro , è lavoro su reference to the argument, non sulla sua copia, ma ancora, il lavoro effettivo all'interno della procedura comporta la copia dei valori, non funziona nella stessa memoria. (Bene, OK, questo non si applica a LOB, ma non è quello che hai chiesto.)

PL/SQL è un linguaggio procedurale su SQL. È progettato per consentire l'utilizzo procedurale di SQL, non è progettato per essere superveloce, superefficace. Se hai bisogno di andare fino alla modifica dei byte direttamente in memoria, potresti voler usare C o assemblatore.

+0

Ciao, hai un riferimento per _Se si tratta di una procedura con un parametro in out nocopy, funziona sul riferimento all'argomento, non sulla sua copia, ma comunque, il lavoro effettivo all'interno della procedura comporta la copia dei valori, non funziona nella stessa memoria ._? –

+0

Oltre a @FlorinGhita sarebbe bello avere qualche riferimento per * Se è una funzione (come nel caso delle dette routine utl_raw), restituisce sempre una nuova istanza di un valore *.Questo è indicato nella domanda senza doc ref anche. La tua risposta non offre molte ** nuove ** informazioni sull'argomento. –

+0

Non so cos'altro posso dirti? C'è semplicemente un buon senso che mi sta dicendo che restituire i valori dalle funzioni implica semplicemente la copia della memoria, come avviene sempre con i compiti di base 'variable: = variable'. – nop77svk

Problemi correlati