Re: PQftable insufficient for primary key determination

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> mmc(at)maruska(dot)dyndns(dot)org (Michal =?iso-8859-2?q?Maru=B9ka?=) writes:
>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>>> The problem is you haven't said what it is you want to distinguish.
>
>> SELECT * from A, A ....
>
>> gives a result table like:
>
>> p | data | p |data |....
>> --------------------
>> 1 | xxx | 2 | yyy | ...
>
>
>> Now you edit the value 'yyy' and want to commit this change to the DB:
>
>> update A set data = 'zzz' where p = primary-key-value;
>
>> How to determine what to use for 'primary-key-value'? The value from the 1st
>> column (PQftable gives A) or from the 3rd column (PQftable gives A again)?

> 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.

That should be solvable by the data editing applications. Having the mapping
(result-column -> relation instance), and detecting the primary key should be
sufficient to solve it, imo.

I want to offer the user the possibility to submit hand written SQL, and edit
what is 'editable' (and possibly propagating the changes to other cells of the result).

But i still think, that the code which provides the PQftable info walks the plan
'tree' following the :varno & other info which i don't know well, and in the
end, having some index to an array of used 'instances' of relations, translates
the index into a plain relname, _throwing_ away a possibly useful info (which
could group some columns as coming from the same 'instance'/ tuples).

> If you have knowledge about the form of the query that's sufficient to
> guarantee that this problem won't occur, then I'd suggest taking another
> look at that knowledge and seeing if it doesn't offer a solution. But
> in the perfectly general form that you've stated the issue, I don't see
> a solution.

This should be a general data editor. Sure, the user should include enough
attributes in the SELECT. And it should work w/ VIEWs too.

And i hope to obtain this info from the information
provided by the server itself.

> regards, tom lane

thanks for your attention.