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 A
On Sun, Oct 21, 2012 at 11:35 PM, P. Christeas wrote:
> On Sunday 21 October 2012, Vik Reykja wrote:
> > On Sun, Oct 21, 2012 at 6:20 PM, Abhijit Menon-Sen
> wrote:
> > > Note: "INSERT … RETURNING" doesn't accept an ORDER BY clause.
> >
> > Would anyone be opposed to somebody - say, me - writing
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 o
On 21 October 2012 16:59, Kevin Grittner 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 (pgsql-hackers@postgre
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
Phil Sorber 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. We've not
fel
"Kevin Grittner" 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 your subsc
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
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:
I'm not sure if this has come up before.
A client was just finding difficulties because to_char() doesn't support
formatting the timezone part of a timestamptz numerically (i.e. as
+-hhmm) instead of using a timezone name. Is there any reason for that?
Would it be something worth having?
ch
On Sunday 21 October 2012, Vik Reykja wrote:
> On Sun, Oct 21, 2012 at 6:20 PM, Abhijit Menon-Sen
wrote:
> > 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 ex
On Mon, Oct 15, 2012 at 9:18 PM, Tom Lane wrote:
> Phil Sorber writes:
>> On Mon, Oct 15, 2012 at 7:12 PM, Tom Lane wrote:
>>> Yeah, I know a whole new executable is kind of a pain, and the amount of
>>> infrastructure and added maintenance seems a bit high compared to what
>>> this does. But a
On Sun, Oct 21, 2012 at 6: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
Andrew Dunstan 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 has. So I think
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 ge
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
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 INT
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 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
Andrew Dunstan 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, I hope
--- hea
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:
> I
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 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 * from
Andrew Dunstan writes:
> On 10/21/2012 12:20 PM, Abhijit Menon-Sen wrote:
>> Note: "INSERT ... RETURNING" doesn't accept an ORDER BY clause.
> No, but you can wrap the INSERT .. RETURNING in a CTE and order that.
This is all a lot more dangerous than it looks, though. Whether or not
you believe
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 offer
Magnus Hagander 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 idea that the only
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 elsewhe
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 usua
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 sl
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: "I
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
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 expec
> -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 tha
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 sugg
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 li
Hello
2012/10/20 Peter Geoghegan :
> 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 patch committed duri
On Saturday, October 20, 2012 11:03 PM Jeff Janes wrote:
On Fri, Sep 7, 2012 at 6:14 AM, Amit kapila 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 Janes wrote:
> On Mon,
On Mon, Oct 15, 2012 at 1:21 PM, Will Crawford
wrote:
> On 14 October 2012 22:17, Daniel Farina 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 configuration, and now you have all p
On Thu, Oct 18, 2012 at 5:59 PM, Robert Haas wrote:
> On Thu, Oct 18, 2012 at 7:20 AM, Magnus Hagander 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 of some previously deprecated fea
On Tue, 2012-09-04 at 17:45 +0400, Alexander Korotkov wrote:
> On Mon, Aug 20, 2012 at 12:25 AM, Jeff Davis
> wrote:
> I am taking a look at this patch now. A few quick comments:
>
> * It looks like bounds_adjacent modifies it's by-reference
> arguments,
>
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.
R
41 matches
Mail list logo
