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
On Thu, 2012-10-18 at 15:09 -0300, Alvaro Herrera wrote:
Jeff, do you think we need more review of this patch?
In the patch, it refers to rd_options without checking for NULL first,
which needs to be fixed.
There's actually still one place where it says id rather than is.
Just a nitpick.
On Tue, 2012-09-04 at 17:45 +0400, Alexander Korotkov wrote:
On Mon, Aug 20, 2012 at 12:25 AM, Jeff Davis pg...@j-davis.com
wrote:
I am taking a look at this patch now. A few quick comments:
* It looks like bounds_adjacent modifies it's by-reference
On Thu, Oct 18, 2012 at 5:59 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Oct 18, 2012 at 7:20 AM, Magnus Hagander mag...@hagander.net wrote:
Since Simon stirred up a hornets nest suggesting deprecation of a
number of features, I figured I'd take it one step further and suggest
removal
On Mon, Oct 15, 2012 at 1:21 PM, Will Crawford
billcrawford1...@gmail.com wrote:
On 14 October 2012 22:17, Daniel Farina dan...@heroku.com wrote:
The problem there is that it's a pain to get signed certs in, say, a
test environment, so don't check certs will make its way into the
default
On Saturday, October 20, 2012 11:03 PM Jeff Janes wrote:
On Fri, Sep 7, 2012 at 6:14 AM, Amit kapila amit.kap...@huawei.com wrote:
On Thursday, September 06, 2012 2:38 PM Amit kapila wrote:
On Tuesday, September 04, 2012 6:55 PM Amit kapila wrote:
On Tuesday, September 04, 2012 12:42 AM Jeff
Hello
2012/10/20 Peter Geoghegan pe...@2ndquadrant.com:
I think that we're both going to be busy next week, since we're both
attending pgconf.eu. For that reason, I would like to spend some time
tomorrow to get something in shape, that I can mark ready for
committer. I'd like to get this
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
On Sun, Oct 21, 2012 at 09:55:50AM +0200, Magnus Hagander wrote:
I don't see a problem at all with providing the snakeoil cert. In
fact, it's quite useful.
I see a problem with enabling it by default. Because it makes people
think they are more secure than they are.
So, what you're
-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
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
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:
Robert Haas wrote:
You know, if we implemented what Tom proposed here:
http://archives.postgresql.org/pgsql-hackers/2012-08/msg01055.php
...then we probably get away with removing pg_size_pretty(bigint)
and then this would Just Work. pg_size_pretty(numeric) is doubtless
a little slower
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 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.
Magnus Hagander mag...@hagander.net writes:
I don't see a problem at all with providing the snakeoil cert. In
fact, it's quite useful.
I see a problem with enabling it by default. Because it makes people
think they are more secure than they are.
I am far from an SSL expert, but I had the
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
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
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,
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
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 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
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 Mon, Oct 15, 2012 at 9:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Phil Sorber p...@omniti.com writes:
On Mon, Oct 15, 2012 at 7:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah, I know a whole new executable is kind of a pain, and the amount of
infrastructure and added maintenance seems a bit
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
On Thu, 2012-10-18 at 16:31 +, Murphy, Kevin wrote:
It might be nice for psql to have a 'htmlcaption' boolean pset option that
would wrap the provided title/caption, if any, in a caption tag in the HTML
report output, when using html format.
I'm not following. It does do that already:
Kevin Grittner wrote:
Will apply tomorrow if there are no further objections.
Done.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Kevin Grittner kgri...@mail.com writes:
Kevin Grittner wrote:
Will apply tomorrow if there are no further objections.
Done.
This needs to be back-patched, no?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Phil Sorber p...@omniti.com writes:
Here is the new patch. I renamed the utility from pg_ping to pingdb to
go along with the naming convention of src/bin/scripts.
Uh, no, that's not a step forward. Leaving out a pg prefix from those
script names is universally agreed to have been a mistake.
Tom Lane wrote:
This needs to be back-patched, no?
Looking at that now.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 21 October 2012 16:59, Kevin Grittner kgri...@mail.com wrote:
I don't know about anyone else, but I could live with that.
Me too.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-hackers mailing list
Kevin Grittner wrote:
Tom Lane wrote:
This needs to be back-patched, no?
Looking at that now.
Back-patched to 9.2. I don't know how I got it in my head that this
was a pending 9.3 feature. I'll check next time, even if I think I
know.
Thanks to both Andres and Tom for pointing that out.
Sorry It might be late here, but just wanted to share the patch
I came up with. Actually with Robert told he reported issues to
pgsql-hacker, I thought he might have also submitted patch.
PFA I came up with, but seems like issue has been already
committed.
Thanks,
On Sat, Oct 20, 2012 at 9:07
39 matches
Mail list logo
