SQL·테스트 데이터

SQL 자리표시자를 바꿀 때 인수 순서는?

사용할 도구

라이브러리를 바꾼 뒤 SQL은 실행돼도 다른 기록을 찾는다면 인수 순서가 원인일 수 있습니다. :user를 $1로 바꿀 때 SQL과 전달 값을 함께 확인하세요. 작은 예제로 대응표를 확인하며 쿼리는 실행하지 않습니다.

변환할 SQL

SELECT * FROM orders WHERE owner = :user AND state = :state;

이름 있는 인수

{"user":"demo","state":"open"}

named 입력·postgresql 출력을 선택하고 JSON을 넣으면 SQL 출현 순서에 따라 :user는 $1, :state는 $2입니다. JSON 키 순서가 아닙니다. arguments에서도 각각 demo·open인지 확인하세요.

출력 형식은 번호형 자리표시자이지 SQL 방언 전체 변환이 아닙니다. 날짜 함수·자료형·식별자 규칙은 따로 확인하세요.

두 열에서 같은 사용자 찾기

SELECT * FROM tasks WHERE owner = :user OR reviewer = :user;

{"user":"demo"}이면 번호형은 두 곳 모두 $1이지만 물음표형 인수는 demo·demo 두 위치입니다. 같은 기호라도 각 출현 위치는 별개입니다.

parameters는 출현별 대응, arguments는 대상에 전달할 값입니다. 출현 수와 값의 정체성을 구분하고 이름 재사용 자체가 의도인지 확인하세요.

인수가 아닌 기호

SELECT ':user' AS note FROM tasks WHERE owner = :user; -- :user

WHERE의 표시만 바뀝니다. 따옴표 안은 데이터, 끝은 주석입니다. 일괄 치환과 달리 남아야 할 부분도 검토하세요.

모든 SQL 확장을 이해하지는 않습니다. 특수 인용·연산자·형변환은 별도 검토가 필요합니다. PostgreSQL의 ?는 연산자일 수 있어 해당 변환을 거부합니다. 오류만 없애려고 방언을 바꾸지 마세요.

SQL은 :user만 쓰는데 state도 있으면 오래된 설정일 수 있습니다. 누락·추가 키는 오류이며 위치형은 JSON 배열 개수를 검사합니다. 빈 값을 보태기보다 어느 쪽이 낡았는지 찾으세요.

변환 성공이 드라이버 지원을 뜻하지는 않습니다. 공식 SQL·인수 전달 규약과 격리 데이터로 결과를 확인하세요. 문자열 연결 대신 바인딩을 유지하고 비밀값이 아닌 가상 값을 쓰세요.