2012/10/21 Albert Cervera i Areny alb...@nan-tic.com:
A Dimecres, 17 d'octubre de 2012 19:13:47, Merlin Moncure va escriure:
On Wed, Oct 17, 2012 at 9:29 AM, Peter Geoghegan pe...@2ndquadrant.com
wrote:
On 17 October 2012 14:53, Merlin Moncure mmonc...@gmail.com wrote:
Is that defined in
I agree that it seems inappropriate to preserve order. That seems an
inappropriate imposition, inconsistent with what SQL does elsewhere.
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
On Sunday, October 21, 2012 06:30:14 PM Andrew Dunstan wrote:
On 10/21/2012 12:20 PM, 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
On Sunday, October 21, 2012 07:24:52 PM Andrew Dunstan wrote:
On 10/21/2012 12:36 PM, Andres Freund wrote:
On Sunday, October 21, 2012 06:30:14 PM Andrew Dunstan wrote:
On 10/21/2012 12:20 PM, Abhijit Menon-Sen wrote:
At 2012-10-21 11:49:26 -0400, cbbro...@gmail.com wrote:
If there is a
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
On Sunday, October 21, 2012 08:45:31 PM Andrew Dunstan wrote:
On 10/21/2012 01:40 PM, Andres Freund wrote:
Suppose you have something like
CREATE TABLE positionlog(
id serial primary key,
timestamp timestamptz DEFAULT NOW(),
position geometry
);
And you want to insert multiple
A Dimecres, 17 d'octubre de 2012 19:13:47, Merlin Moncure va escriure:
On Wed, Oct 17, 2012 at 9:29 AM, Peter Geoghegan pe...@2ndquadrant.com
wrote:
On 17 October 2012 14:53, Merlin Moncure mmonc...@gmail.com wrote:
Is that defined in the standard?
RETURNING isn't even defined in the
On Wed, Oct 17, 2012 at 7:38 AM, P. Christeas x...@linux.gr wrote:
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.
Is that defined in the standard?
merlin
--
Sent via pgsql-hackers mailing list
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.
eg: INSERT INTO tbl1(code) VALUES ('abc'), ('def'), ('agh')
RETURNING id, code;
is expected to yield:
On 17 October 2012 14:53, Merlin Moncure mmonc...@gmail.com wrote:
Is that defined in the standard?
RETURNING isn't even defined in the standard.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-hackers
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
On Wed, Oct 17, 2012 at 9:29 AM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 17 October 2012 14:53, Merlin Moncure mmonc...@gmail.com wrote:
Is that defined in the standard?
RETURNING isn't even defined in the standard.
Right: Point being, assumptions based on implementation ordering are
12 matches
Mail list logo
