Crei una clausola WHERE SQL parametrizzata dai filtri

Ogni nome di campo viene racchiuso come identificatore SQL, compresi i singoli segmenti di un nome qualificato, mentre i valori restano fuori dal testo SQL. I filtri mantengono l’ordine originale e sono uniti tramite AND, per un risultato prevedibile in generatori di query, strumenti amministrativi, schermate di report ed endpoint che ricevono già i filtri come dati.

Costruisca la struttura SQL senza concatenare i valori

Le schermate di ricerca dinamica spesso partono da record apparentemente innocui: un campo, un operatore e un valore. Il passaggio rischioso consiste nel trasformarli in SQL inserendo direttamente il valore in una stringa. Questo generatore mantiene separati struttura e dati. Restituisce una clausola WHERE SQL parametrizzata con segnaposto posizionali in stile PostgreSQL, come $1 e $2, oltre a un array params nello stesso identico ordine. Inserisca la clausola in un’istruzione SELECT, UPDATE o DELETE più ampia e fornisca params a un driver compatibile. Il generatore non esegue query, non si collega al database, non analizza lo schema e non decide quali colonne possa usare il chiamante. Se gli utenti possono influenzare i campi, l’applicazione deve comunque mantenere una lista di valori consentiti. Le virgolette impediscono a punteggiatura e parole riservate di danneggiare la sintassi, ma l’autorizzazione resta responsabilità dell’applicazione. Poiché i filtri vengono uniti con AND nell’ordine fornito, l’output è stabile e semplice da registrare, confrontare o combinare con un prefisso di query fisso.

Comprenda operatori, segnaposto e controlli sui null

Gli operatori supportati includono uguaglianza, disuguaglianza, confronti di ordinamento, LIKE, NOT LIKE, IN, NOT IN, IS NULL e IS NOT NULL. Il testo dell’operatore viene normalizzato in maiuscolo e gli spazi ripetuti sono compressi, quindi una forma come “not like” produce SQL canonico. Ogni confronto ordinario usa un parametro. IN e NOT IN richiedono un array non vuoto e lo espandono in un segnaposto per elemento, mantenendone l’ordine. Gli operatori sui null non usano parametri e non richiedono un valore, perché la loro grammatica SQL non contiene segnaposto. L’assenza del valore per qualsiasi altro operatore genera un errore invece di SQL incompleto. Sono accettati valori scalari JSON, comprese stringhe, numeri, booleani e null; gli array sono riservati ai due operatori di elenco. Il risultato usa intenzionalmente segnaposto numerati con il simbolo del dollaro, adatti a PostgreSQL e alle librerie compatibili. Se il Suo driver usa punti interrogativi o parametri denominati, converta la sintassi in un adattatore controllato conservando l’ordine restituito.

Protegga gli identificatori e convalidi la politica applicativa

Ogni campo viene trattato come identificatore eventualmente qualificato. Un nome come users.created_at diventa due segmenti racchiusi separatamente, mentre una virgoletta doppia interna viene protetta raddoppiandola secondo le regole standard degli identificatori SQL. I nomi vuoti e i segmenti vuoti separati da punti sono rifiutati. Questo trattamento impedisce che una stringa di campo venga confusa con sintassi SQL non racchiusa, ma non presume che tutti i motori adottino regole identiche. Verifichi la compatibilità con il database di destinazione, soprattutto se non segue la convenzione delle virgolette doppie. Inoltre, proteggere non equivale ad autorizzare. Se un chiamante esterno sceglie i campi, associ le chiavi pubbliche a un insieme esplicito di colonne reali prima di invocare il generatore. Applichi anche regole aziendali agli operatori: un endpoint di report può consentire uguaglianza e intervalli ma rifiutare i pattern, sebbene LIKE sia supportato. Un operatore SQL sconosciuto produce sempre un chiaro errore di input. La capacità è deterministica, non effettua richieste di rete e restituisce soltanto la clausola e i parametri.