npgsql CommandType.StoredProcedure는 이제 함수 대신 프로시저를 호출합니다.

NpgsqlCommand.CommandType를 로 설정하면 Npgsql 은 이전과 같이 함수 가 아닌 CommandType.StoredProcedurePostgreSQL 저장 프로시저를 호출하기 위한 SQL을 생성합니다 . 이 주요 변경을 옵트아웃하고 이전과 같이 함수를 계속 호출하려면 다음과 같이 AppContext 스위치를 활성화합니다.Npgsql.EnableStoredProcedureCompatMode

AppContext.SetSwitch("Npgsql.EnableStoredProcedureCompatMode", true);

맥락상 PostgreSQL은 원래 기능만 지원했으며 저장 프로시저의 표준 SQL 개념은 지원하지 않았습니다. 이로 인해 CommandType.StoredProcedure함수를 호출하도록 구현되었습니다. 그런 다음 PostgreSQL 11에서는 일부 시나리오(예: 트랜잭션 사용 기능)의 기능에 비해 다양한 이점을 갖는 저장 프로시저를 도입했습니다. 7.0 릴리스에서는 CommandType.StoredProcedure이름에서 알 수 있듯이 프로시저를 호출하도록 변경되었으며 더 나은 호환성을 위해 Npgsql을 다른 데이터베이스 공급자와 정렬합니다.

CommandType.StoredProcedureNpgsql을 사용하면 단순히 SQL을 통해 함수나 프로시저를 호출하는 것보다 이점이 없습니다 . 실제로 그렇게 하는 것이 좋습니다.

// Invoke a procedure
using var command1 = new NpgsqlCommand("CALL some_procedure($1, $2)", connection)
{
    new() { Value = "some_value" },
    new() { Value = "some_other_value" }
};

// Invoke a function
using var command2 = new NpgsqlCommand("SELECT * FROM some_function($1, $2)", connection)
{
    new() { Value = "some_value" },
    new() { Value = "some_other_value" }
};

연결 수준에서 유형 매핑 관리는 더 이상 지원되지 않습니다.

이전 버전의 Npgsql에서는 연결 수준에서 사용자 지정 유형(enums/composites) 매핑과 플러그인(NetTopologySuite, NodaTime) 구성이 허용되었습니다. 유형 매핑 변경은 연결 수명 동안만 유지되며 연결이 닫히면 되돌려집니다. 이 메커니즘은 비효율적이었습니다. 연결이 자주 열리고 닫히며 내부적으로 상당한 유지 관리 부담이 추가되었습니다.

의 도입으로 NpgsqlDataSourceNpgsql은 이제 유형 매핑을 관리하기 위한 자연스러운 API 포인트를 갖게 되었습니다.

var dataSourceBuilder = new NpgsqlDataSourceBuilder("Host=localhost;Username=test;Password=test");
dataSourceBuilder.MapEnum<MyEnum>();
dataSourceBuilder.UseNodaTime();
await using var dataSource = dataSourceBuilder.Build();

데이터 소스에서 전달되는 모든 연결은 구성된 유형 매핑을 사용합니다.

전역적으로 유형 매핑을 관리하는 것은 NpgsqlConnection.GlobalTypeMapper이전과 같이 지원되지만 더 이상 사용되지 않는 것으로 표시되었습니다. 조만간 전역 유형 매핑을 제거할 계획은 없지만 이제 Npgsql Data Source Builder는 유형 매핑을 관리하는 데 권장되는 방법입니다.