Re: Search path in connection string

Поиск
Список
Период
Сортировка
От Valentine Gogichashvili
Тема Re: Search path in connection string
Дата
Msg-id CAP93muXF=qH=3JiuLL_i1w09rssAB_QCjvb_t1qEaTzW-3pvNg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Search path in connection string  (Dave Cramer <pg@fastcrypt.com>)
Ответы Re: Search path in connection string
Список pgsql-jdbc
Hello Dave, 

sorry, did not see your reply. I will try to write a patch. 

There is one issue, with the patch implementation: 

1. try to stay "backwards compatible", i.e. try to search in all existing schemas but prefer the one from the search_path order (actually I do not know if it really makes sense)
2. simply search according to search_path parameter, i.e. fail in case the schema is not seen by the search_path logic

Regards,

-- Valentine Gogichashvili


On Tue, Jul 31, 2012 at 10:18 PM, Dave Cramer <pg@fastcrypt.com> wrote:
Valentine,

Any chance you could recreate that patch against current sources ?

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca


On Tue, Jul 31, 2012 at 3:40 PM, Valentine Gogichashvili
<valgog@gmail.com> wrote:
> On Tue, Jul 31, 2012 at 8:05 PM, Julien Demoor <jdemoor@gmail.com> wrote:
>>
>> 2012/7/31 Valentine Gogichashvili <valgog@gmail.com>
>>>
>>> Hello Julien,
>>>
>>> As normally you would always use a connection pool (like BoneCP or c3p0),
>>> you can easily configure an InitSQL property to initialize your connection
>>> as needed.
>>>
>>> Note that JDBC driver for now does not support search_path at all, as the
>>> OID cache lookup is not taking it into an account. So prepare for some crazy
>>> problems when for example returning a type that exists in several schemas
>>> with the same name.
>>>
>>> With best regards,
>>>
>>> -- Valentine
>>
>>
>> Hello Valentine,
>>
>> I'll see if connection pools are available with BIRT (I'm using the
>> integrated web viewer so I can't go around its limitations).
>>
>> Thanks for the tip regarding the support for the search_path. Should I
>> expect issues if the types that share a name across schemas have the same
>> definition?
>>
>> Regards,
>> Julien
>
>
> Hello Julien,
>
> You can always write a simple wrapper, that will override getConnection()
> and preinizialize there as needed.
>
> The problem is now, that OID cache for types does not take into an account
> search_path at all. So if you have 2 types, that have the same name in 2
> different schemas, one of them will be taken practically randomly, and if
> you do not have luck, it will take the wrong one and postgres will throw a
> crazy exception when the driver will try to use the wrong OID when passing
> this type as a parameter for example.
>
> But it is very easy to patch the driver in case you will get such a problem.
> I suggested one quick-n-dirty patch once, and filed a bug report without a
> patch... (http://archives.postgresql.org/pgsql-jdbc/2011-03/msg00007.php,
> http://archives.postgresql.org/pgsql-jdbc/2011-12/msg00083.php) but both
> messages had been ignored unfortunately.
>
> You can have a look in wich case I am getting a problem there here:
> http://tech.valgog.com/2012/01/schema-based-versioning-and-deployment.html
>
> Regards,
>
> -- Valentin
>
>
>

В списке pgsql-jdbc по дате отправления:

Предыдущее
От: Euler Taveira
Дата:
Сообщение: Re: translation updates
Следующее
От: Luis Flores
Дата:
Сообщение: Re: Search path in connection string