Re: Search path in connection string

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(at)fastcrypt(dot)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(at)gmail(dot)com> wrote:
> > On Tue, Jul 31, 2012 at 8:05 PM, Julien Demoor <jdemoor(at)gmail(dot)com>
> wrote:
> >>
> >> 2012/7/31 Valentine Gogichashvili <valgog(at)gmail(dot)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
> >
> >
> >
>