구차니의 잡동사니 모음

select 문만 쓰다가 update를 join을 통해 하려니 신기한 느낌?

update 문에 table이 하나 있으니 FROM 으로 다른 테이블을 정해주면 자연스럽게(?) join이 된다.

[링크 : https://xshine.tistory.com/209]

select로 추려낸 결과를 다른 select - where 문에서 쓰기 위한 방법

[링크 : https://stackoverflow.com/questions/1136380/sql-where-in-clause-multiple-columns]

+

2019.10.04

라는데.. 굳이 이걸 써야 하나 싶긴하네

select * from where (val1_upper, val2_upper) in (select val1,val2 from something)

temporary file leak: File 4 still referenced

아.. 먼가 불안한 경고다.. 

일단 급한건 아니니 나중에 봐야지..

[링크 : https://dba.stackexchange.com/questions/112079/slow-query-performance-due-to-temporary-file]

regexp_matches()는 여러개가 매칭될수 있어서 array()로 리턴하는데

{} 로 쌓여 있어서 그걸 벗기기 위해서는 unnest()를 하는게 가장 간단한데..

select 까진 문제없으나..

udpate 시에는 multiple row가 나올 녀석은 아예 배제가 되니 주의

[링크 : https://stackoverflow.com/questions/10593400/remove-braces-from-regular-expression-result]

unnest를 사용하니 ,로 구분된 리스트를 여러개의 열로 나눌수 있었다.

string_to_array()의 반대 개념이라고 하면 되려나?

regexp_split_to_table() 도 사용할 수 있으나 regexp의 cost가 비싼 편이라 추천은 안하는 듯

[링크 : https://stackoverflow.com/questions/29419993/split-column-into-multiple-rows-in-postgres]

  [링크 : https://www.postgresql.org/docs/current/functions-string.html#FUNCTIONS-STRING-OTHER]

+

예제에 따라 다르지만 select에서 써도 되고 from에서 lateral join으로 구현해도 되고

어느게 cost가 낮을려나?

[링크 : https://www.postgresql.org/docs/9.2/functions-array.html]

[링크 : https://wwwi.tistory.com/350]

+

[링크 : https://www.postgresql.org/docs/9.3/functions-matching.html]

[링크 : https://www.postgresdba.com/bbs/board.php?bo_table=B10&wr_id=44]

테이블 하나의 값을 바꿔치기하는데 특정 조건에 맞게 넣는방법

근데.. 특이하게도.. postgresql에서 순서가 뒤죽박죽이 된다..

recored가 원래 1부터 100까지 순서대로 나왔는데

update table set colname = 

case when condition then val1;

end;

이렇게 돌리니

뒤죽박죽으로 나온다. 실행 정책인가?

[링크 : https://blog.naver.com/50after/220930638267]

말은 거창한데..

sequence나 mysql 기준 auto increment 지정된 Pk 값을 나중에 추가해서

그 값을 넣어줄때 쓰는 방법

UPDATE table SET column = nextval('seq_name') 하면 해결!

정말.. SQL 문이 강력하구나.. 라는걸 느끼는 중

[링크 : https://fle.github.io/reset-a-postgresql-sequence-and-recompute-column-values.html]

문법은 미지원

유사하게 case로 구현은 가능하나

추후 값에 따라 자동으로 유사한것 끼리 묶는건 불가능 할 듯

[링크 : https://stackoverflow.com/questions/6101404/sql-group-by-like]

having 은 조건에 만족하지 않는 그룹 rows를 제거한다. HAVING은 WHERE과는 다르다: WHERE는 GROUP BY의 적용 전에 개별 rows를 필터하는 대신 HAVING는 GROUP BY에 의해 생성된 group rows를 필터한다.

(해석은 하는데 무슨 뜻이여...

일단은 생성하고 나서 하나하나 생성하냐, 아니면 그룹으로 묶이는 애들 레벨에서 미리 처리하냐 차이인가?)

[링크 : https://www.postgresql.org/docs/9.5/sql-select.html]