Re: Roadmap for FE/BE protocol redesign - Mailing list pgsql-hackers

From Dave Page
Subject Re: Roadmap for FE/BE protocol redesign
Date
Msg-id 03AF4E498C591348A42FC93DEA9661B8259D8E@mail.vale-housing.co.uk
Whole thread Raw
In response to Roadmap for FE/BE protocol redesign  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

> -----Original Message-----
> From: Merlin Moncure [mailto:merlin.moncure@rcsonline.com] 
> Sent: 12 March 2003 13:35
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org
> Subject: RE: [HACKERS] Roadmap for FE/BE protocol redesign
> 
> 
> > values. That code is just plain nasty in VB. In pgAdmin III we've
> already
> > mentioned stealing bits of the PostgreSQL parser.
> 
> Do not be swayed by the dark side.  In my spare time I threw 
> together a
> 'proof of concept' replacement for the technology used in 
> pgAdmin.   It
> is written in C++.  In three seconds I can query a table and 
> put 100000 records in a grid.  I plan to finish it and 
> release it.  The main reason not to use it is that it relies 
> on commercial tools to build.  
> 
> If you or anybody else is intereted, let me know and I'll 
> send it your way.

You do realise I'm the pgAdmin project lead? Anyway, the 'technology' in
pgAdmin II is ADO/ODBC which I quite agree doesn't play well with that
many records - but then, not many humans do either.

In pgAdmin III we use libpq directly from C++. If you can speed up that
then I'm sure there will be more people than just me that are interested
:-)

The code I'm actually referring too in this thread, is that which
decides whether and how the results from a given query can be updated.
That would be vastly simplified is I could easily locate the
pg_attribute row for each column.

Regards, Dave.

pgsql-hackers by date:

Previous
From: "Dave Page"
Date:
Subject: Re: Roadmap for FE/BE protocol redesign
Next
From: Dave Cramer
Date:
Subject: Re: Roadmap for FE/BE protocol redesign