Re: [RFC] ideas for a new Python DBAPI driver (was Re: [HACKERS] libpq test suite)
On Thursday 14 February 2013, Manlio Perillo wrote: Il 14/02/2013 14:06, Albe Laurenz ha scritto: Manlio Perillo wrote: Sorry for the question, but where can I find the libpq test suite? I can not find it in the PostgreSQL sources; it seems that there are only some examples, in src/test/examples. For my Python DBAPI2 PostgreSQL driver I plan the following optimizations: 1) always use PQsendQueryParams functions. This will avoid having to escape parameters, as it is done in psycopg2 (IMHO it still use simple query protocol for compatibility purpose) 2) when the driver detects a Python string is being sent to the database, use binary format. As a special case, this will avoid having to use PQescapeByteaConn when sending binary string (e.g. byte strings in Python 3.x) Perhaps you could also see some attempt I'd made to support binary protocol inside psycopg2, some time ago: https://github.com/xrg/psycopg/tree/execparams2 -- Say NO to spam and viruses. Stop using Microsoft Windows! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_top
On Thursday 20 December 2012, Brett Maton wrote: Hi List, This might not be the right place to post, but I've got a minor patch for pg_top and would like to submit it for review. This project lies on Github: https://github.com/markwkm/pg_top/ I think, this commit had fixed the issue you are talking about: https://github.com/markwkm/pg_top/commit/a211ac3f161d7ec2752ed038009f93b4f470e86c -- Say NO to spam and viruses. Stop using Microsoft Windows! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [PATCH] Enforce that INSERT...RETURNING preserves the order of multi rows
On Sunday 21 October 2012, Abhijit Menon-Sen wrote: At 2012-10-21 11:49:26 -0400, cbbro...@gmail.com wrote: If there is a natural sequence (e.g. - a value assigned by nextval()), that offers a natural place to apply the usual order-imposing ORDER BY that we are expected to use elsewhere. Note: INSERT … RETURNING doesn't accept an ORDER BY clause. Exactly. And IMHO it should never have. The real trouble is when you insert some arbitrary values, which have no implicit order or primary key /before/ the insert will assign them one. Then, you need to map them to the SERIAL they got. Or else, you can't use the multi-row INSERT and must just do many INSERTs. -- Say NO to spam and viruses. Stop using Microsoft Windows! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] Enforce that INSERT...RETURNING preserves the order of multi rows
On Sunday 21 October 2012, Andres Freund wrote:
On Sunday, October 21, 2012 07:24:52 PM Andrew Dunstan wrote:
why does the client have to be involved, exactly?
Suppose you have something like
CREATE TABLE positionlog(
...
And you want to insert multiple values in one roundtrip *and* know their
ids in your application.
INSERT INTO positionlog(position)
VALUES
('POINT(..., ...)'),
('POINT(..., ...)')
RETURNING id, timestamp, position
;
If you want to correlate re returned ids with data in your application
without relying on the ordering of INSERT ... VALUES... RETURNING you
would need to sort a postgis type in the same way the server does it.
Am I missing something here?
That's close enough to my case: you would have to guess from (timestamp,
position) the order they have with respect to your [(timestamp, pos),...]
input array. That's not always trivial to do client-side (what about duplicate
pairs? ), let alone the CPU needed to sort and match again.
--
Say NO to spam and viruses. Stop using Microsoft Windows!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [PATCH] Enforce that INSERT...RETURNING preserves the order of multi rows
On Sunday 21 October 2012, Vik Reykja wrote: On Sun, Oct 21, 2012 at 6:20 PM, Abhijit Menon-Sen a...@2ndquadrant.comwrote: Note: INSERT … RETURNING doesn't accept an ORDER BY clause. Would anyone be opposed to somebody - say, me - writing a patch to allow that? It would take me a lot longer than an experienced hacker to do it, but I'm willing to try. I would oppose, for one. Please, don't waste your time. Reordering the INSERT .. RETURNING results is already possible today, with some nested syntax. At the same time, bloating the INSERT syntax with SELECT semantics would be negative IMO. And I would see little use in having such a feature. At a worst case scenario, you could do (in client pseydocode): ids = query(INSERT INTO tableA (col1, col2) VALUES (...), (...) RETURNING id) ordered_ids = query(SELECT id FROM tableA WHERE id IN %s ORDER BY col1, ids) which would be minimally more roundtrip than a RETURNING id ORDER BY col1 . -- Say NO to spam and viruses. Stop using Microsoft Windows! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] Enforce that INSERT...RETURNING preserves the order of multi rows
On Wednesday 17 October 2012, you wrote: P. Christeas x...@linux.gr writes: It has been a fact that the RETURNING clause on an INSERT will return multiple rows with the same order as multiple VALUES have been fed. I don't believe this is a good idea in the slightest. Yeah, the current implementation happens to act like that, but there is no reason that we should make it guaranteed behavior. That's my point, to push you to decide on that feature and clarify it in the documentation. So far, it's very tempting for me to use this behavior, since I can avoid multiple INSERTs (=save bandwidth) and also the burden of figuring out which of the returned ids associates to which inserted row. Having a discussion (or argument or a vote) like this, I think, is useful. FYI, there is also a stack overflow question on this: http://stackoverflow.com/questions/5439293/is-insert-returning-guaranteed-to- return-things-in-the-right-order -- Say NO to spam and viruses. Stop using Microsoft Windows! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
