From: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Dave Page <dpage(at)vale-housing(dot)co(dot)uk>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Roadmap for FE/BE protocol redesign |
Date: | 2003-03-13 01:45:22 |
Message-ID: | 3E6FE2B2.E7E38C14@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut wrote:
>
> Dave Page writes:
>
> > Well what I *really* need has been made quite clear in other
> > posts, but, when I say resultset in the same sentence as
> > pgAdmin, I'm referring to the ability to enter an arbitrary
> > SQL query, have the results displayed in a grid, which can
> > then be editted. To do this pgAdmin needs to be able to
> > figure out enough info about the source of the data to generate
> > the required insert/update/delete statements.
>
> Right. But since you can't really write a literal SQL statement
> that does an update that refers to a previous query, you are
> already doing a fair amount of internal magic anyway, so if the
> meta-data is determined by magic as well, that seems consistent.
Psqlodbc driver has to parse the queries in order to
implement driver side updatable cursors unwillingly.
I'm very suspicios if it should be the driver's job
because it's very hard and ineffective to parse and
analyze the queries in the same way as the backend does.
> What you need is an updateable cursor on the server side.
> It has all the facilities you need,
Really ? How did you confirm it ?
> including standardized ways to find out the
> updatability metadata. Please concentrate on that and do not attempt to
> clutter the wire protocol with data that will not withstand a throrough
> investigation of semantics.
regards,
Hiroshi Inoue
http://www.geocities.jp/inocchichichi/psqlodbc/
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2003-03-13 01:55:30 | Re: Roadmap for FE/BE protocol redesign |
Previous Message | Joe Conway | 2003-03-13 01:30:07 | Re: regproc's lack of certainty is dangerous |