Re: Roadmap for FE/BE protocol redesign - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Roadmap for FE/BE protocol redesign
Date
Msg-id 1047467308.1817.5.camel@fuji.krosing.net
Whole thread Raw
In response to Re: Roadmap for FE/BE protocol redesign  (Barry Lind <blind@xythos.com>)
List pgsql-hackers
Barry Lind kirjutas K, 12.03.2003 kell 10:43:
> Dave Page wrote:
> > I don't know about JDBC, but ODBC could use it, and it would save a heck
> > of a lot of pain in apps like pgAdmin that need to figure out if a column
> > in an arbitrary resultset might be updateable.
> > At the moment there is some nasty code in pgAdmin II that attempts to
> > parse the SQL statement to figure out if the the resultset is updateable
> > by trying to figure out the number of relations in the query, whether any
> > of them is a view or sequence, whether there are any function calls or
> > expressions in the attribute list and so on. It then has to try to figure
> > out if there is a complete pkey in the resultset that can be used for the
> > update, or whether it should attempt an update based on all existing
> > values. That code is just plain nasty in VB. In pgAdmin III we've already
> > mentioned stealing bits of the PostgreSQL parser.
> 
> I will just add a "me to" here.  This would be very useful for JDBC as 
> well.  We go through the same hoops to support the jdbc spec that Dave 
> does.  The jdbc spec has two features that require this level of 
> information:
...

> Now one can state the spec is broken and it doesn't make sense to ask 
> this type of information about a query (and frankly I would agree with 
> you), but that doesn't mean that I don't need to support it anyway.  So 
> anything that the server can do to make this easier is greatly 
> appreciated.  And I believe ODBC has almost the exact same issue since 
> in general the JDBC spec was copied from the ODBC spec.

And IIRC they both are mostly the same as ANSI/ISO SQL/CLI spec. The CLI
being Call Level Interface.

> 2) Updateable result sets.  The jdbc spec allows the user to declare any 
> select statement to be updateable.  This means that as you scroll 
> through the result (the ResultSet object) you can issue modify the data 
> and expect the jdbc driver to reflect that change back to the base 
> tables.  The following if from the JDBC API doc:
...
> Now application developers love this functionality.  It allows them to 
> implement fairly complex apps with very little sql knowledge.  They only 
> need to know how to do a simple select statement and that is it.  The 
> jdbc driver handles the rest for them automatically (updates, inserts, 
> deletes).  As a jdbc maintainer I personally hate this functionality as 
> it is a real pain to implement, and can't work in any but the most 
> simple select statements.  But is is part of the spec and needs to be 
> supported in the best manner possible.

Updatable cursors should probably come out as a side benefit when
backend gains the ability to have updatable views. If you have done some
work towards implementing it in JDBC driver, some it will probably be
handy for anyone who is going to implement updatable views.

-----------------
Hannu



pgsql-hackers by date:

Previous
From: "Zeugswetter Andreas SB SD"
Date:
Subject: Re: Roadmap for FE/BE protocol redesign
Next
From: "Sander Steffann"
Date:
Subject: Re: Numbering of the next release: 8.0 vs 7.4