Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] JDBC pg_description update needed for CVS

From: Jeroen van Vianen <jeroen(dot)van(dot)vianen(at)satama(dot)com>
To: Rene Pijlman <rene(at)lab(dot)applinet(dot)nl>
Cc: Barry Lind <barry(at)xythos(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-jdbc(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] JDBC pg_description update needed for CVS
Date: 2001-09-09 12:48:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-jdbcpgsql-patches
At 00:18 9/9/2001 +0200, Rene Pijlman wrote:
>On Fri, 07 Sep 2001 01:34:46 -0400, Tom Lane wrote:
> >there is still an unpatched reference to pg_description in
> >getColumns(), in both jdbc1 and jdbc2.
>This was introduced by Jeroen's patch (see
> Attached
>is a patch that returns getColumns() to using "select
>obj_description()" instead of direct access to pg_description,
>as per the request by Tom.
>I've incorporated Jeroen's fix to left outer join with
>pg_attrdef instead of inner join, so getColumns() also returns
>columns without a default value.
>I have, however, not included Jeroen's attempt to combine
>multiple queries into one huge multi-join query for better
>performance, because:
>1) I don't know how to do that using obj_description() instead
>of direct access to pg_description

Exactly. That's why I put a comment in my orginal mail 
( about not being able 
to use the col_description in a (left) outer join and used the actual code 
of col_description instead. Is it possible to do:

select t1.*, f from t1 left outer join 
function_returning_a_single_row_or_null(parameters) f ?

I think this should be possible, but I have no clue how/whether the grammar 
and/or executor should be changed to allow this. Or someone with more 
experience with outer join SQL syntax might be able to help here.

>2) I don't think a performance improvement (if any) in this
>method is very important

It is of course a performance improvement if it uses only 1 SQL statement 
rather than N+1 with N being the number of columns reported. E.g. if you 
list all columns of all tables in a big database, this would be a huge win. 
I noted that some of the JDBC MetaData functions in the Oracle JDBC driver 
were really slow compared to PostgreSQL's (e.g. seconds slower).

>Because of the outer join, getColumns() will only work with a
>backend >= 7.1. Since the conditional coding for 7.1/7.2 and
>jdbc1/jdbc2 is already giving me headaches I didn't pursue a
>pre-7.1 solution.



In response to


pgsql-hackers by date

Next:From: Jim ButtafuocoDate: 2001-09-09 12:50:33
Subject: pg_dump -C option
Previous:From: Jim ButtafuocoDate: 2001-09-09 12:44:40
Subject: PG_DUMP -C option

pgsql-patches by date

Next:From: Rene PijlmanDate: 2001-09-09 12:58:40
Subject: Re: [HACKERS] JDBC pg_description update needed for CVS tip
Previous:From: Marc BalmerDate: 2001-09-09 08:53:15
Subject: date_part patch

pgsql-jdbc by date

Next:From: Rene PijlmanDate: 2001-09-09 12:50:35
Subject: NULLs and sort order
Previous:From: Rene PijlmanDate: 2001-09-09 09:47:05
Subject: Re: Regarding Error installing jdbc7.0-1.2.jar

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group