[CBRD-27043] Expose db_histogram with name columns and the standard SELECT-privilege filter

[soheejung-cs]

http://jira.cubrid.org/browse/CBRD-27043

Purpose

db_histogram 시스템 뷰에서 두 가지를 고칩니다.

1. class_name 컬럼이 OBJECT 타입이었습니다. _db_histogram.class_of 가 클래스 객체(MOP) 자체를 저장하는데 뷰가 이를 그대로 내보내서, WHERE class_name = 't1' 같은 문자열 비교가 '=' operator is not defined on types object and char 로 실패했습니다.

2. 권한 필터가 없었습니다. 다른 시스템 뷰(db_index, db_partition, db_attribute)는 DBA 그룹 / 소유자 / SELECT 피부여자만 행을 볼 수 있게 WHERE 절로 걸러내는데, 이 뷰만 예외여서 SELECT 권한이 없는 테이블의 히스토그램 존재 여부·수집 방식·NULL 비율을 누구나 조회할 수 있었습니다.

3. class_name 이 OBJECT 를 벗어나면서 시스템 클래스의 일반 object 도메인 개수가 9 에서 8 로 줄어듭니다. 이 개수는 CNT_CATCLS_OBJECTS 로 하드코딩돼 있고 TRUNCATE 가 "이 테이블을 참조하는 사용자 클래스가 있는가" 를 판정하는 기준선이라, 함께 내리지 않으면 참조를 놓칩니다.

겸사겸사 컬럼 이름과 도메인을 다른 시스템 뷰의 규약에 맞춰 정리했습니다.

Implementation

• sm_define_view_histogram_spec() (schema_system_catalog_install_query_spec.cpp)

  • _db_class [c] 를 [h].[class_of] = [c].[class_of] 로 조인해 owner_name, class_name 을 문자열로 내보냅니다.
  • db_attribute 뷰와 같은 3단 권한 필터를 WHERE 에 추가했습니다. _db_auth.object_of 와 _db_histogram.class_of 가 같은 클래스 객체이므로 {[h].[class_of]} SUBSETEQ (SELECT SUM (SET {[au].[object_of]}) …) 로 바로 비교합니다.
  • 컬럼: owner_name, class_name, attr_name(구 key_attr), scan_type(구 with_fullscan, 'FULL SCAN' / 'SAMPLING SCAN'), null_frequency. 스펙의 ORDER BY 는 다른 시스템 뷰처럼 제거했습니다.
  • 권한 절이 들어가 버퍼를 2048 → 4096 으로 늘렸습니다(확장 후 실제 길이 1064).

• system_catalog_initializer::get_view_db_histogram() (schema_system_catalog_install.cpp)

  • 뷰 컬럼 도메인이 스펙 결과 타입을 덮어쓰므로 class_name 을 VARCHAR(255) 로, null_frequency 를 스펙의 CAST 와 같은 NUMERIC(18, 12) 로 선언했습니다(기존에는 double 이라 CAST 가 무효였고 0.000000000000000e+00 로 출력됐습니다).

• CNT_CATCLS_OBJECTS (schema_system_catalog_constants.h) 9 → 8

  • schema_class_truncator.cpp 는 일반 object 도메인 개수 + 대상 클래스를 가리키는 도메인 개수를 CNT_CATCLS_OBJECTS + 1 로 캡을 걸어 세고, 기준선을 넘으면 "사용자 클래스가 참조한다" 로 봅니다. 9 로 두면 참조가 있는 DONT_REUSE_OID 테이블도 8 + 1 = 9 가 되어 참조 없음으로 읽히고, TRUNCATE 가 행 삭제 대신 heap 을 파괴·재생성합니다 — 그 옵션이 막으려던 OID 재사용이 그대로 일어납니다.
  • 헤더와 truncator 의 CAUTION 주석이 상수는 9 인데 본문은 6 이라고 적고 있어 실제 개수와 출처를 함께 정리했습니다.

동작 확인 (새 DB, csql 출력 그대로)

준비:

-- dba
CREATE TABLE towned(k INT, v VARCHAR(20));  INSERT ... 3000 rows;  UPDATE STATISTICS ON towned WITH FULLSCAN;
CREATE TABLE tpub(k INT);  INSERT INTO tpub VALUES (1),(2);  UPDATE STATISTICS ON tpub WITH FULLSCAN;
CREATE USER u1 PASSWORD '';  GRANT SELECT ON tpub TO u1;   -- u1 has no privilege on towned

수정 전 (upstream/develop 과 동일한 뷰 정의):

-- dba: SELECT class_name, key_attr, with_fullscan, null_frequency FROM db_histogram;
  class_name            key_attr              with_fullscan                   null_frequency
============================================================================================
  dba.towned            'k'                   'full scan'              0.000000000000000e+00
  dba.towned            'v'                   'full scan'              0.000000000000000e+00
  dba.tpub              'k'                   'full scan'              0.000000000000000e+00

-- dba: SELECT key_attr FROM db_histogram WHERE class_name = 'towned';
ERROR: '=' operator is not defined on types object and char.

-- u1: SELECT COUNT(*) FROM dba.towned;
ERROR: SELECT is not authorized on dba.towned.

-- u1: SELECT class_name, key_attr, with_fullscan, null_frequency FROM db_histogram;
  class_name            key_attr              with_fullscan                   null_frequency
============================================================================================
  dba.towned            'k'                   'full scan'              0.000000000000000e+00
  dba.towned            'v'                   'full scan'              0.000000000000000e+00
  dba.tpub              'k'                   'full scan'              0.000000000000000e+00
3 rows selected.

-- u1: SELECT class_name, owner_name FROM db_index;   (same user, view with the privilege filter)
There are no results.

수정 후 (이 PR):

-- dba: SELECT owner_name, class_name, attr_name, scan_type, null_frequency FROM db_histogram ORDER BY 1,2,3;
  owner_name            class_name            attr_name             scan_type             null_frequency
==============================================================================================================
  'DBA'                 'towned'              'k'                   'FULL SCAN'           0.000000000000
  'DBA'                 'towned'              'v'                   'FULL SCAN'           0.000000000000
  'DBA'                 'tpub'                'k'                   'FULL SCAN'           0.000000000000
3 rows selected.

-- dba: SELECT attr_name FROM db_histogram WHERE class_name = 'towned';
  attr_name
======================
  'k'
  'v'
2 rows selected.

-- u1: SELECT owner_name, class_name, attr_name, scan_type, null_frequency FROM db_histogram ORDER BY 1,2,3;
  owner_name            class_name            attr_name             scan_type             null_frequency
==============================================================================================================
  'DBA'                 'tpub'                'k'                   'FULL SCAN'           0.000000000000
1 row selected.

-- dba: SELECT attr_name, data_type, prec, scale FROM db_attribute WHERE class_name = 'db_histogram' ORDER BY def_order;
  attr_name             data_type                    prec        scale
======================================================================
  'owner_name'          'STRING'                       32            0
  'class_name'          'STRING'                      255            0
  'attr_name'           'STRING'                      255            0
  'scan_type'           'STRING'                       32            0
  'null_frequency'      'NUMERIC'                      18           12

Remarks

• 뷰 정의는 createdb 시점에 카탈로그에 저장되므로 이 변경 전에 만든 DB 에는 반영되지 않습니다(다른 시스템 뷰 변경과 같은 조건). 히스토그램은 미출시 기능이라 마이그레이션은 두지 않았습니다.

• 컬럼 이름 변경(key_attr → attr_name, with_fullscan → scan_type)은 매뉴얼·TC·엔진 소스에 기존 참조가 없음을 확인했습니다.

• 히스토그램 값(MCV·버킷 경계)은 계속 뷰에 내보내지 않습니다. ;info histogram 경로가 SELECT 권한을 검사합니다(JIRA 종결 코멘트 참조).

• 자기 리뷰(리뷰 하네스)에서 걸러낸 것: scan_type CASE 의 ELSE 가 NULL 을 접는 이유를 주석으로 남겼습니다(with_fullscan 은 항상 0/1 int).

• 기존 JIRA 종결 코멘트의 「비고」에서 "메타데이터라 결함 아님" 으로 남겨 두었던 항목을 이번에 함께 고쳤습니다.

• CI 실패 5건을 분류해 전부 이 변경으로 귀속시켰습니다. 그 중 둘은 답안이 아니라 위 상수 누락이 만든 실제 회귀였습니다.

  케이스	스위트	성격	처리
  use_delete (cbrd_23954)	shell	TRUNCATE 가 heap 을 파괴해 vfid 변화 — DONT_REUSE_OID 보호 상실	상수 수정으로 해소, 답안 무변경
  bug_3339 (CUBRIDSUS-3339)	sql	TRUNCATE 후 dangling OID 역참조가 NULL 대신 이전 값 22	상수 수정으로 해소, 답안 무변경
  catcls_general_object (cbrd_23954)	shell	일반 object 도메인 개수 9 → 8 (이 개수를 감시하는 케이스)	답안 정렬
  bug_xdbms_sus575	shell	compactdb -v 의 _db_attribute·_db_domain 인스턴스 수	답안 정렬
  19_user_cursor_system_view	sql	db_attribute 소유자별 건수 +1	답안 정렬

  cbrd_20149_xasl 의 truncate 답안 5건은 플랜 덤프가 truncator 의 질의문을 그대로 싣기 때문에 ROWNUM <= 10 → <= 9 로 함께 정렬했습니다.

• CBRD-27382 과 같은 상수를 반대 방향으로 움직입니다 — 머지 순서에 따라 값이 달라집니다. CBRD-27382(_db_index 가 인덱스 행 OID 대신 참조 클래스를 저장)는 일반 object 도메인을 하나 늘려 9 → 10 으로 만들고, 이 PR 은 하나 줄여 9 → 8 로 만듭니다. 둘 다 들어가면 9 입니다. 지금은 CBRD-27382 의 엔진이 develop 에 없으므로(develop 상수 = 9) 이 PR 기준은 8 이고 TC 답안도 8 / ROWNUM <= 9 입니다. 나중에 머지되는 쪽이 상수와 답안을 ±1 조정해야 합니다 — CBRD-27382 의 TC 답안(10 / <= 11)은 이미 TC develop 에 있으니, 그 엔진이 먼저 들어가면 이 PR 을 리베이스해 9 / <= 10 으로 올려야 합니다.

• upstream/develop 882e87144 위로 리베이스했습니다. 그 과정에서 들어온 CBRD-26354 때문에 필요해진 답안(bug_bts_4670.answer)만 TC 브랜치로 체리픽했고, CBRD-27382 의 답안 변경은 이 PR 의 엔진 상태와 맞지 않으므로 의도적으로 가져오지 않았습니다.

• 로컬 검증(release 15279602e, 리베이스 전 트리 — 리베이스로 들어온 develop 4건은 TRUNCATE·카탈로그를 건드리지 않습니다): use_delete 24/24 OK, catcls_general_object 2/2 OK, bug_3339 는 22 / NULL / 22 두 블록 모두 답안과 일치(자동커밋 off). TC 브랜치 tc/pr-7976 는 양쪽 리포에 푸시했습니다.

🤖 Generated with Claude Code

https://claude.ai/code/session_01QBMgWWzmrvFiQBSBUiL2YD

[github-actions]

✅ TC Merge Gate — Merge Allowed

All TC PRs are merged, closed, or not present.

TC Repositories & Branches:

• ✅ cubrid-testcases: No open TC PR (merged, closed, or not created)
• ✅ cubrid-testcases-private-ex: No open TC PR (merged, closed, or not created)

[github-actions]

🧪 TC Test Environment Ready

CircleCI Testing:

• CircleCI will automatically test using the branches below.

TC Repositories & Branches:

• cubrid-testcases Draft PR (Branch: tc/pr-7976)
• cubrid-testcases-private-ex Draft PR (Branch: tc/pr-7976)

Next Steps:

1. Wait for CircleCI tests to complete
2. If CircleCI tests failed, please check the test results and fix the issues.
3. When ready to merge this PR, please merge the TC PR first, then merge this PR.

[greptile-apps]

확인된 차단 또는 비차단 결함이 없어 현재 변경은 병합해도 안전해 보인다.

_{Reviews (1) · Last reviewed commit: "[CBRD-27043] Note that with_fullscan is ..."}

[soheejung-cs]

/run all

[soheejung-cs]

/run all

[soheejung-cs]

/run all

[soheejung-cs]

/run all

[soheejung-cs]

/run rerun 35326279522

[github-actions]

✅ TC Branch Finalized for cubrid-testcases

Engine PR was merged.

Cleanup Results:

TC base branch is ready for the next PR.

[github-actions]

✅ TC Branch Finalized for cubrid-testcases-private-ex

Engine PR was merged.

Cleanup Results:

TC base branch is ready for the next PR.