policyname | tablename | cmd | roles | qual | with_check |
---|---|---|---|---|---|
Enable read access for all users | users | SELECT | {public} | true | null |
Enable insert for authenticated users only | users | INSERT | {authenticated} | null | true |
Enable update for users based on email | users | UPDATE | {public} | ((( SELECT auth.jwt() AS jwt) ->> 'email'::text) = (users_email)::text) | ((( SELECT auth.jwt() AS jwt) ->> 'email'::text) = (users_email)::text) |
supabase
로 회원가입 로직을 구현하기 위해 사전 설정 상황을 확인해 보던 중, users_email
의 column type
이 varchar
로 되어 있는 사실을 확인했다. 이 부분은 사정 설정 당시에 값의 길이가 변동될 수 있는 문자열 데이터로 저장하기 위해 일부러 설정했던 것인데, 권장되지 않는 사항으로 경고창이 떴다.
CHAR VARCHAR 문자열 비교 시에 공백을 채워서 비교 공백도 하나의 문자로 취급
CHAR(8) 이고 'AA' 를 저장한다면, CAHR에서 'AA' = 'AA ' 는 AA 가 채워지고 남은 6자리에 공백을 붙여 'AA ' = 'AA ' 가 되어 같다는 결과가 나온다.
VARCHAR 에서는 공백도 하나의 문자로 취급하기 때문에, 끝에 공백이 들어가면 다른 문자로 판단해 'AA' != 'AA ' 의 결과가 나온다.
✅ 따라서, 이름, 주소 등의 가변성이 있는 값은 VARCHAR 를 사용하고, 사번이나 주민등록번호 같은 일정한 길이의 데이터는 CHAR 을 사용하는 것이 좋다.
1. Supabase 의 자동화된 스키마 관리 편의성
Supabase는 자동 마이그레이션 및 동적 스키마 변경을 지원하는데,
VARCHAR(n)
보다는TEXT
가 이런 관리에 더 유리하기 때문에, 타입이 더 유연한TEXT
타입을 기본적으로 추천한다.++
VARCHAR
타입의 경우, 나중에 길이 제한을 변경해야 할 경우ALTER TABLE
이 필요하다.ALTER TABLE users ALTER COLUMN users_email TYPE VARCHAR(500);
이런 sql 코드를 추가해야 할 지도,,
2. VARCHAR의 최대 길이 지정이 PostgreSQL에서는 필요 없다!
데이터베이스에서
VARCHAR
의 경우 최대 크기가 설정되기 때문에, 메모리 공간을 실제 크기와 관계 없이 최대 크기로 미리 할당해 둔다. 하지만TEXT
나BLOB
과 같은, large object 의 경우 실제 최대 크기만큼 메모리를 할당해 두면 메모리 낭비가 심해진다. 따라서VARCHAR
을 사용하면 성능 최적화에 유리하다.하지만 supabase 는
PostgreSQL
을 기반으로 하는 백엔드 서비스이다. 그리고PostgreSQL
에서는VARCHAR(n)
과TEXT
가 동일한 방식으로 처리된다. 즉, 성능의 차이가 없다! 그렇기 때문에 뭔가 이유가 있지 않은 이상TEXT
타입으로 처리하는 것이 더 좋다.3. Supabase의 인증 시스템과의 호환성
데이터베이스에서
VARCHAR
의 경우 최대 크기가 설정되기 때문에, 메모리 공간을 실제 크기와 관계 없이 최대 크기로 미리 할당해 둔다. 하지만TEXT
나BLOB
과 같은, large object 의 경우 실제 최대 크기만큼 메모리를 할당해 두면 메모리 낭비가 심해진다. 따라서VARCHAR
을 사용하면 성능 최적화에 유리하다.
백엔드의 데이터 타입 관리에 대한 매우 흥미로운 공부였다!