Stored procedures with unqualified table names not working with Babelfish - stored-procedures

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, i.e. select * from biz.cities