[JDBC] default fetch size

2001-09-15 Thread Dave Thompson

Hi all,

I'm doing some research into tightly coupling data mining applications to
PostgreSQL, and have a couple of questions:

1) What's the default fetch size set by the jdbc driver (jdbc7.0-1.2.jar)?

2) Is there any way to change this other than by editing the source code?
The setFetchSize and getFetchSize methods are not supported.

Thanks for your help.

Dave Thompson.
Research Student.
University of Manchester, England.
[EMAIL PROTECTED]


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [JDBC] isNullable()

2001-09-15 Thread Rene Pijlman

Attached is a patch that fixes ResultSetMetaData.isNullable() in
the JDBC driver.

This method is currently unimplemented and always returns
ResultSetMetaData.columnNullable. This is obviously incorrect
when a column is defined with NOT NULL or PRIMARY KEY. And we
have to think of check constraints, views, functions etc.

The patch simply changes the return value to
ResultSetMetaData.columnNullableUnknown. This is until someone
comes up with a real implementation of course.

On Fri, 14 Sep 2001 17:53:50 +0200, Tomisaw Kityñski wrote:
Hello there,

could someone tell me, please, do I have any chance to get
proper implementation of above method in JDBC (1.1+) soon?

Current return 1 works fine on most tables, however it seems
to be a little bit incorrect with some of them ;)


Regards,
René Pijlman [EMAIL PROTECTED]


Index: org/postgresql/jdbc1/ResultSetMetaData.java
===
RCS file: 
/home/projects/pgsql/cvsroot/pgsql/src/interfaces/jdbc/org/postgresql/jdbc1/ResultSetMetaData.java,v
retrieving revision 1.5
diff -c -r1.5 ResultSetMetaData.java
*** org/postgresql/jdbc1/ResultSetMetaData.java 2001/09/06 20:43:39 1.5
--- org/postgresql/jdbc1/ResultSetMetaData.java 2001/09/15 19:35:09
***
*** 136,144 
}

/**
!* Can you put a NULL in this column?  I think this is always
!* true in 6.1's case.  It would only be false if the field had
!* been defined NOT NULL (system catalogs could be queried?)
 *
 * @param column the first column is 1, the second is 2...
 * @return one of the columnNullable values
--- 136,142 
}

/**
!* Indicates the nullability of values in the designated column.
 *
 * @param column the first column is 1, the second is 2...
 * @return one of the columnNullable values
***
*** 146,154 
 */
public int isNullable(int column) throws SQLException
{
! return columnNullable;// We can always put NULL in
}
!   
/**
 * Is the column a signed number? In PostgreSQL, all numbers
 * are signed, so this is trivial.  However, strings are not
--- 144,157 
 */
public int isNullable(int column) throws SQLException
{
!   /*
!* TODO This needs a real implementation, taking into account columns
!* defined with NOT NULL or PRIMARY KEY, CHECK constraints, views, 
!* functions etc.
!*/
! return columnNullableUnknown;
}
! 
/**
 * Is the column a signed number? In PostgreSQL, all numbers
 * are signed, so this is trivial.  However, strings are not
Index: org/postgresql/jdbc2/ResultSetMetaData.java
===
RCS file: 
/home/projects/pgsql/cvsroot/pgsql/src/interfaces/jdbc/org/postgresql/jdbc2/ResultSetMetaData.java,v
retrieving revision 1.5
diff -c -r1.5 ResultSetMetaData.java
*** org/postgresql/jdbc2/ResultSetMetaData.java 2001/09/06 20:43:39 1.5
--- org/postgresql/jdbc2/ResultSetMetaData.java 2001/09/15 19:35:09
***
*** 131,139 
}

/**
!* Can you put a NULL in this column?  I think this is always
!* true in 6.1's case.  It would only be false if the field had
!* been defined NOT NULL (system catalogs could be queried?)
 *
 * @param column the first column is 1, the second is 2...
 * @return one of the columnNullable values
--- 131,137 
}

/**
!* Indicates the nullability of values in the designated column.
 *
 * @param column the first column is 1, the second is 2...
 * @return one of the columnNullable values
***
*** 141,147 
 */
public int isNullable(int column) throws SQLException
{
! return columnNullable;// We can always put NULL in
}

/**
--- 139,150 
 */
public int isNullable(int column) throws SQLException
{
!   /*
!* TODO This needs a real implementation, taking into account columns
!* defined with NOT NULL or PRIMARY KEY, CHECK constraints, views, 
!* functions etc.
!*/
! return columnNullableUnknown;
}

/**



---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



[JDBC] UpdateableResultSet patch (not finished yet!)

2001-09-15 Thread Ola Sundell

Hello,

I have, for some time, now, been working on the updateable resultset
class. Please have a look at http://www.miranda.org/~ola/jdbcupr.diff, and
let me know what you think. It is only rudimentary at the moment.

Things to consider:

* Parsing of query. Very hackish at the moment.
* Concurrency check.

Things that need work:
* Documentation
* Inserting - nothing done as of yet.
* The test case needs to be more elaborate.

Ola

-- 
Ola Sundell
[EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED]
http://miranda.org/~ola



---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [HACKERS] [JDBC] NULLs and sort order

2001-09-15 Thread Tom Lane

Peter Eisentraut [EMAIL PROTECTED] writes:
 Rene Pijlman writes:
 Currently the JDBC driver says:
 - Backend = 7.2 sorts nulls higher than any other value in a
 domain. In other words: ascending means nulls at the end,
 descending means nulls at the start.
 - Backend  7.2 puts nulls at the end regardless of sort order.

 That is correct.

Actually it's more complex than that.  7.2 will provide the above-stated
consistent ordering of nulls relative to non-nulls.  The problem with
earlier versions is that the ordering of nulls depends on what plan the
optimizer chooses for the query: sorting based on a scan of a btree
index would work the same as is described for 7.2, whereas sorting
based on an explicit sort step would put the nulls at the end (for
either ASC or DESC sort).  So there was *no* consistent behavior at all
in prior versions.  The fix that's been applied for 7.2 is to make
explicit sorts act the same as indexscans already did.

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org