具有不合格表名的存储过程不适用于 Babelfish

Question

I have created a Babelfish-enabled Postgres database in RDS. I connected with SSMS and created a Database named 'demo'. Within 'demo' I created a Schema named 'biz'. I created my tables and stored procedures in the 'biz' schema. The stored procedures used unqualified table names. Finally, I wrote a.Net program to do some testing. I use the System.Data.SqlClient Connection and Command classes and I can connect to the database. When I execute a stored procedure I get the 'relation "X" does not exist.' error. If I alter my stored procedure and qualify the table names with the 'biz' schema the error goes away.

How do I avoid having to qualify the table names with the schema?

For example: After creating a Babelfish enabled Postgres cluster I executed these statements in SSMS:

create database demo
use demo
create schema biz
create table [biz].[cities](
    [city] varchar(128),
    [state] varchar(128)
    )

create procedure [biz].[p_getcities] as
begin
    select * from cities
end

insert into [biz].[cities](city, state) values ('Portland', 'OR')
insert into [biz].[cities](city, state) values ('Richmond', 'VA')

exec [biz].p_getcities

And I get this error message after running p_getcities:

Msg 33557097, Level 16, State 1, Line 21 relation "cities" does not exist

When I switch to pgAdmin and try to run the stored procedure like this:

CALL biz.p_getcities()

I get a similar error:

ERROR: relation "cities" does not exist LINE 1: select * from cities ^ QUERY: select * from cities CONTEXT: PL/tsql function biz.p_getcities() line 2 at SQL statement SQL state: 42P01

However, when I set the search_path like this:

set search_path to biz

And the execute the stored procedure I get the expected results:

Portland OR Richmond VA

Is there an equivalent to search_path in Babelfish?

Answer 1

This explanation has been provided by Rob Verschoor of rcv-aws

What is happening here is that the name resolution inside the procedure biz.p_getcities does not correctly resolve the table name. It resolves it to 'dbo' schema while it should resolve it to 'biz' schema. As you noted, this is related to the search_path setting, and this is not set correctly in this case. This is a known bug and we hope to fix it soon.

Until then, the workaround is to qualify the table name with the schema name, ie select * from biz.cities