Re: Search path in connection string
От | Dave Cramer |
---|---|
Тема | Re: Search path in connection string |
Дата | |
Msg-id | CADK3HHK4cLS6e-PnAG6crJDd-F71+neVaYv8S65J2Et-w9_nfg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Search path in connection string (Valentine Gogichashvili <valgog@gmail.com>) |
Ответы |
Re: Search path in connection string
|
Список | pgsql-jdbc |
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 по дате отправления: