Re: PQftable insufficient for primary key determination - Mailing list pgsql-general

From Kris Jurka
Subject Re: PQftable insufficient for primary key determination
Date
Msg-id Pine.BSO.4.56.0407161305370.26415@leary.csoft.net
Whole thread Raw
In response to Re: PQftable insufficient for primary key determination  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general

On Fri, 16 Jul 2004, Tom Lane wrote:

> I don't think this is a well-defined problem.  What does the user think
> he's doing when he edits yyy of the join output?  There may be multiple
> copies of that value in the output table, if the row that it came from
> joined to multiple rows in the other tables.  In that case it would be
> impossible to alter a single field value without changing other rows of
> the displayed result.  So at least in the general case, I don't think
> it makes sense to allow editing of fields of join results.

I agree, but something that would be nice along these lines is the ability
to detect if the results from a user provided query are from a join.  For
example the JDBC driver supports updatable ResultSets and right now the
detection code to determine if a given query can be updated involves a
very broken inspection of the query string.  I was thinking this could be
done by checking the source tables of the result.  At the moment this
can't tell if a self join is involved.  It would also have problems in
a situation where a join was performed but only columns from one table
were selected.  Allowing an update here could affect multiple rows of the
result, but still should only affect one source row.  I don't like this
idea, but I don't have any better ideas than trying to implement a full
sql parser in the JDBC driver.  Perhaps this will have to wait for
updatable cursors.

Kris Jurka


pgsql-general by date:

Previous
From: Jean-Luc Lachance
Date:
Subject: Re: Column as result of subtraction of two other columns?
Next
From: o.blomqvist@secomintl.com (Otto Blomqvist)
Date:
Subject: Need Libpq.dll w/ SSL