| From: | "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk> | 
|---|---|
| To: | "Peter Eisentraut" <peter_e(at)gmx(dot)net> | 
| Cc: | "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 14:43:22 | 
| Message-ID: | 03AF4E498C591348A42FC93DEA9661B8259D8C@mail.vale-housing.co.uk | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
> -----Original Message-----
> From: Peter Eisentraut [mailto:peter_e(at)gmx(dot)net] 
> Sent: 12 March 2003 00:34
> To: Dave Page
> Cc: Tom Lane; PostgreSQL Development
> Subject: Re: [HACKERS] Roadmap for FE/BE protocol redesign
> 
> 
> Dave Page writes:
> 
> > I don't know about JDBC, but ODBC could use it, and it would save a 
> > heck of a lot of pain in apps like pgAdmin that need to 
> figure out if 
> > a column in an arbitrary resultset might be updateable.
> 
> Strictly speaking, result sets are never updatable, because 
> there's no way you can refer to a result set and tell the 
> system to update it.  So let's hear what you *really* need 
> and then consider interfaces for *that*. Maybe updatable 
> views or updatable cursors?
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.
It also happens that ODBC, JDBC etc, also need the same information to
meet their specs.
Regards, Dave.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dave Page | 2003-03-12 14:49:15 | Re: Roadmap for FE/BE protocol redesign | 
| Previous Message | Hiroshi Inoue | 2003-03-12 14:32:45 | Re: Roadmap for FE/BE protocol redesign |