Thread: PGAPI_Columns() does not follow search path

Trying to get the columns though odbc
we have a namespace 'user' so when we log in as that user
and the searchpath is $user,public

when queried for columns from a table that exists in public
the postgres-unixodbc driver specifically does a select current_schema()
and uses that to restrict the queries to the namespace 'user'
(all other SQL queries don't do this and allow the full search_path())

if I do the same query without the namespace restriction the columns are
returned
as expected.

Is there a particular reason why this query is limited to the namespace.

I notice there is a specific workaround if the 'specified name space' ==
'name'
then it will try public as well but only if current == public
but since there is a current namespace == the user this code doesn't
fire

This looks like someone trying to solve somewhat the same problem,
would it not be better to just remove the namespace restriction
and let it follow the search_path.

Ken Faiczak

Hello,

I want to substitue an existing DB2 to PG 8 and got a Problem. Much of our
applications are written in Cobol and are using ODBC Interface to get data.
With DB2, that runs.

The Problem is now in my Test Environment when I connect to PG that I can
read everything well except german umlaute (ä, ü,...). I always get "?" and
not the umlaut.
My database's encoding is LATIN1. Windows Codepage tried with 850 and 1252.

When I read with client-side encoding UNICODE, I got the umlaute, but I
cannot write them to PG. Wirte statements like INSERTs work with LATIN1
encoding.

But something that never worked is, when I send a statement which should
return values with umlaute in it and which have umlaute in a WHERE-clause.
like: SELECT...FROM...WHERE text='ä';

I have tested it under WinNT as well as under WinXP. Same problem. Does
anyone have an idea?

Greetings,
R M Kramer

Hello,

If I have understood the PostgreSQL ODBC driver, it supports
Unicode on Windows. In that case, the database needs to be in UTF-8.

In the World, there is a LATIN1 -> UTF-8(UNICODE) transition going on.
So, LATIN1 users have a higher risk of finding new faults, like
this one in the PostgreSQL ODBC driver.


In my opinion, DB2 works, because the DB2 ODBC client driver
does charset conversions from the database charset into the
client charset and vice versa.

I don't know the current state of PostgreSQL ODBC on this regard.
It would be very nice, if the database server could be in UTF-8
and some old application would use LATIN1 and some new
application could use UTF-8 at the same time ...

Regards,
Marko Ristola

Robert Max Kramer wrote:

> Hello,
>
> I want to substitue an existing DB2 to PG 8 and got a Problem. Much of
> our applications are written in Cobol and are using ODBC Interface to
> get data. With DB2, that runs.
>
> The Problem is now in my Test Environment when I connect to PG that I
> can read everything well except german umlaute (ä, ü,...). I always
> get "?" and not the umlaut.
> My database's encoding is LATIN1. Windows Codepage tried with 850 and
> 1252.
>
> When I read with client-side encoding UNICODE, I got the umlaute, but
> I cannot write them to PG. Wirte statements like INSERTs work with
> LATIN1 encoding.
>
> But something that never worked is, when I send a statement which
> should return values with umlaute in it and which have umlaute in a
> WHERE-clause. like: SELECT...FROM...WHERE text='ä';
>
> I have tested it under WinNT as well as under WinXP. Same problem.
> Does anyone have an idea?
>
> Greetings,
> R M Kramer
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
>               http://archives.postgresql.org