Re: Search path in connection string

I would recommend to do the strict implementation (only honor
search_path), and define a new connection parameter
(search_all_schemas=true) which would be default for now, to maintain
the old behavior.

If one wants the strict behavior just add search_all_schemas=false to
the connection url, and in a later driver revision, change the default
to search_all_schemas=false.

You could also search only by search_path and, if that fails, search
all the rest, and output a warning about it.

In any case, I believe that it should be possible to have strict
behavior within the driver.

Luis Flores

On Thu, Aug 16, 2012 at 4:29 PM, Valentine Gogichashvili
<valgog(at)gmail(dot)com> wrote:
> 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
>> >
>> >
>> >
>
>