Re: default values - Mailing list pgsql-jdbc

Felipe,

To start with you would need to add the method to
org.postgresql.PGStatement interface (that is where the postgresql
specific extensions go).  Then the implementation should go into
org.postgresql.jdbc1.AbstractJdbc1Statement so the method is available
to jdbc1, jdbc2 and jdbc3.  As far as only having it valid for 7.3,
there is a method you can call to check the server version and
conditional do this if the server is 7.3, and probably throw an
exception for an older server, just look through the code for other
instances of code called conditionally based on server version.

The hardest part of this patch (I think) is going to be getting this to
work for updateable result sets.  Also adding all the test cases to the
regression tests will take some time as well.  And don't forget the doc
updates.

thanks,
--Barry



Felipe Schnack wrote:
>   Well, there was a way to implement server side prepared statements...
> All PreparedStatements should be server-side... IMHO the way this is
> implemented in pgsql driver is completely non-standard.
>   But I don't mind at all, I like the way it is :-)
>   Oh, yes, I'm repeating over and over for a week that I would like to
> implement it. But I never developed an JDBC driver, much less pgsql
> driver... so I would like some pointers. For instance: where I should
> implement this? AbstractJdbc3PreparedStatement? How I guaratee this will
> be valid only for pgsql 7.3?
>
> On Wed, 2002-11-20 at 02:00, Barry Lind wrote:
>
>>Support for server side prepared statements was added in this way
>>because there is no other easy way to use them in standard jdbc.
>>However in this case there is an easy way to get default values using
>>standard jdbc functionality.  I just don't see any compelling reason to
>>add this extension.
>>
>>But if you want to add it and provide a patch (and especially test all
>>the different cases, like server prepared statements, updateable result
>>sets, callable statements, etc), I would apply the patch, but I don't
>>plan to spend any time working on this myself.
>>
>>--Barry
>>
>>
>>Felipe Schnack wrote:
>>
>>>  So why setUseServerSidePrepare() was implemented? This is not potable,
>>>not standard, not anything.
>>>
>>>On Mon, 2002-11-18 at 22:48, Barry Lind wrote:
>>>
>>>
>>>>Felipe Schnack wrote:
>>>>
>>>>
>>>>> 2- This feature is avaliable in pgsql. Why not implement it?
>>>>>
>>>>
>>>>Since default column capability isn't part of the jdbc standard yet (but
>>>>since it is part of the SQL standard, I would expect it to be added
>>>>someday to the jdbc spec), adding support for it would require the user
>>>>to write non-portable jdbc code.  Since there is a portable way to
>>>>accomplish the same thing (i.e. not include the column in the insert), I
>>>>don't see a compelling reason to add this functionality.
>>>>
>>>>thanks,
>>>>--Barry
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>On Mon, 2002-11-18 at 17:16, Stuart Robinson wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Hi, Felipe.
>>>>>>
>>>>>>I'm been trying to follow the discussion about default values and I'm a little
>>>>>>confused. I think David's reply is sensible. Unless I'm missing something, I
>>>>>>don't think there's an issue for inserts. All you have to do is not specify the
>>>>>>default column in the insert and it will automatically get the default value. I
>>>>>>think the issue only arises when you do updates, if you want to revert to the
>>>>>>default for a column that has been changed since it was originally inserted.
>>>>>>
>>>>>>Ate mais,
>>>>>>Stuart
>>>>>>
>>>>>>Quoting David Wall <David.Wall@Yozons.com>:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Why not simply remove varcharfield2 from the INSERT statement and let the
>>>>>>>database insert that value with the default value?  Isn't the purpose of a
>>>>>>>default value to have the DB put that value in when none is specified?
>>>>>>
>>>>>>--
>>>>>>Stuart Robinson <stuart@zapata.org>
>>>>>>
>>>>>>
>>>>>>-------------------------------------------------
>>>>>>This mail sent through IMP: http://horde.org/imp/
>>>>>
>>>>
>>
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>