From: | Dave Cramer <dave(at)fastcrypt(dot)com> |
---|---|
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-12 17:25:23 |
Message-ID: | 1047489922.1045.43.camel@inspiron.cramers |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 2003-03-12 at 12:46, 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.
>
> What you need is an updateable cursor on the server side. It has all the
> facilities you need, 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.
And I have offered to pay for this work to be done. Someone?
--
Dave Cramer <dave(at)fastcrypt(dot)com>
Cramer Consulting
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2003-03-12 17:46:14 | Re: Roadmap for FE/BE protocol redesign |
Previous Message | Leigh W3NLB | 2003-03-12 17:03:40 | Re: Largest filesize under Linux |