Re: Roadmap for FE/BE protocol redesign

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

In response to

Browse pgsql-hackers by date

  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