At 2012-10-17 09:56:22 -0400, t...@sss.pgh.pa.us wrote:
Clarify that in the documentation, and also write a test case
that will prevent us from breaking the rule in the future.
I don't believe this is a good idea in the slightest. Yeah, the
current implementation happens to act like
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Abhijit Menon-Sen
Sent: Sunday, October 21, 2012 5:45 AM
To: Tom Lane
Cc: P. Christeas; pgsql-hackers@postgresql.org
Subject: [HACKERS] Re: [PATCH] Enforce that
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
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 order-imposing ORDER BY
that we are expected to use elsewhere.
Note:
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.
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 natural sequence (e.g. - a value assigned by nextval()),
that
Andrew Dunstan and...@dunslane.net writes:
Er, what?
with orig_inserts as
(
insert into table_1
...
returning *
),
ordered_inserts as
(
select * from orig_inserts
order by ...
)
insert into table_2
select *
On 10/21/2012 01:39 PM, Tom Lane wrote:
I'm not exactly following what that proves? It seems like this is still
making a not-guaranteed assumption, which is that the outer INSERT isn't
going to choose to rearrange the order of the rows coming from the CTE.
Strictly speaking, even SELECT * FROM
Andrew Dunstan and...@dunslane.net writes:
Hmm. If we do
INSERT INTO foo
SELECT ... ORDER BY
is that not guaranteed to insert in the desired order?
Well, what do you mean by insert in the desired order? Not that the
rows are guaranteed to wind up physically stored in that order,
At 2012-10-21 14:27:39 -0400, t...@sss.pgh.pa.us wrote:
Is that fundamentally an illegitimate optimization, and if so why?
I wouldn't say it's illegitimate. It's a bit less convenient for the
application programmer, and will surprise some people (even some who
know better than to expect SELECT
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 values in one roundtrip *and* know their ids
in your application.
INSERT
On 10/21/2012 02:47 PM, Andres Freund wrote:
On Sunday, October 21, 2012 08:45:31 PM Andrew Dunstan wrote:
I guess in such a case I'd be inclined to precompute the id values and
then supply them in the values clause. That means two round trips rather
than one.
Which will fail should we
Andrew Dunstan and...@dunslane.net writes:
Sufficient unto the day is the evil thereof. It seems premature to worry
about it now.
Um, well, this whole thread is about how many potential optimizations
we're willing to toss aside to guarantee a particular behavior that the
current implementation
On Sun, Oct 21, 2012 at 6:20 PM, Abhijit Menon-Sen a...@2ndquadrant.comwrote:
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
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
15 matches
Mail list logo
