Re: Roadmap for FE/BE protocol redesign
От | Dave Page |
---|---|
Тема | Re: Roadmap for FE/BE protocol redesign |
Дата | |
Msg-id | 03AF4E498C591348A42FC93DEA9661B8259D8E@mail.vale-housing.co.uk обсуждение исходный текст |
Ответ на | Roadmap for FE/BE protocol redesign (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: