On Sun, Jan 5, 2014 at 12:00 PM, Tom Lane wrote:
>
>
> Looking at this example makes me wonder if it wouldn't be worthwhile to
> provide a way to reset and re-use a tuplesort object, instead of redoing
> all the lookup work involved. Or maybe just find a way to cache the
> catalog lookups that ar
From: "Noah Misch"
I agree that English consistently beats mojibake. I question whether that
makes up for the loss of translation when encodings do happen to match,
particularly for non-technical errors like a mistyped password. The
everything-UTF8 scenario appears often, perhaps explaining in
From: "Peter Eisentraut"
On 12/25/13, 6:40 AM, MauMau wrote:
pg_regress must wait for postgres to terminate by calling waitpid(),
because it invoked postgres directly. The attached
pg_regress_pg_stop.patch does this. If you like the combination of this
and the original fix for pg_ctl in one p
From: "Michael Meskes"
On Sat, Dec 28, 2013 at 08:04:09AM +0900, MauMau wrote:
OK, I'll run the ECPG regression test on Solaris without the patch.
Please wait until Jan 6 2014 or so, because we've just entered new
year holidays here in Japan.
Sure, we're no in a particular hurry.
I ran the
On Fri, Jan 3, 2014 at 9:05 AM, Amit Kapila wrote:
> On Fri, Jan 3, 2014 at 12:51 AM, Heikki Linnakangas
> wrote:
>> On 01/02/2014 02:24 PM, Rushabh Lathia wrote:
>>> Do you think we should detoast the local variable before
>>> RollbackAndReleaseCurrentSubTransaction ? Or any other options ?
>>
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> I've committed this after significant editorialization --- most
> Tom> notably, I pushed control of the sort step into the aggregate
> Tom> support functions.
> Initial tests suggest that your version is ~40% slower than ours on
> some
On 01/04/2014 11:11 PM, Tom Lane wrote:
knizhnik writes:
On 01/04/2014 12:05 PM, David Fetter wrote:
Is there some way not to use shared memory for it?
No, IMCS ("In-Memory Columnar Store") is storing data in shared memory.
It would probably be better if it made use of the dynamic shared mem
Andres Freund writes:
> On 2014-01-04 14:06:19 -0500, Tom Lane wrote:
>> And if we have ext. as a prefix, exactly what prevents conflicts in the
>> second part of the name? Nothing, that's what. It's useless.
> Uh? We are certainly not going to add core code that defines relation
> options with
knizhnik writes:
> On 01/04/2014 12:05 PM, David Fetter wrote:
>> Is there some way not to use shared memory for it?
> No, IMCS ("In-Memory Columnar Store") is storing data in shared memory.
It would probably be better if it made use of the dynamic shared memory
features that exist in HEAD.
On 2014-01-04 14:06:19 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-01-04 13:00:03 -0500, Tom Lane wrote:
> >> Assuming that such examples are forthcoming, though, I think my main
> >> objection to this proposal is the "ext." prefix, which seems precisely
> >> 100% useless, not to me
Andres Freund writes:
> On 2014-01-04 13:00:03 -0500, Tom Lane wrote:
>> Assuming that such examples are forthcoming, though, I think my main
>> objection to this proposal is the "ext." prefix, which seems precisely
>> 100% useless, not to mention inconsistent with the naming of custom GUCs,
>> wh
On 2014-01-04 13:00:03 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-01-04 11:54:46 -0500, Robert Haas wrote:
> >> Well, as I said before, somebody can make their own configuration
> >> table and store stuff there, rather than using pg_class.reloptions.
> >> As I recall, the only resp
2014/1/4 Tom Lane
> Pavel Stehule writes:
> > I propose a enhance the PLpgSQL_plugin struct by a new hook
> > void (*pragma)(PLpgSQL_execstate *estate, PLpgSQL_pragma
> > *pragma_stmt)
>
> I repeat what I said a couple of days ago: it's a very bad idea to be
> enabling more plpgsql plugin
Ian Lawrence Barwick writes:
> Presumably "classifyConditions", not "classifyClauses", is meant.
Hm, I think this got missed in a bout of renaming. Will apply, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
Emre Hasegeli writes:
> I am not sure it worth reporting but it took me a while to find out
> what is wrong with comparing two values returned from
> the bitncmp function. It does not return -1, 1 or 0 as it is written
> on the comment when n % 8 == 0.
Yeah, should say "<0, >0, or 0", I guess. W
Andres Freund writes:
> On 2014-01-04 11:54:46 -0500, Robert Haas wrote:
>> Well, as I said before, somebody can make their own configuration
>> table and store stuff there, rather than using pg_class.reloptions.
>> As I recall, the only response to that proposal was "well, they might
>> not want
Pavel Stehule writes:
> I propose a enhance the PLpgSQL_plugin struct by a new hook
> void (*pragma)(PLpgSQL_execstate *estate, PLpgSQL_pragma
> *pragma_stmt)
I repeat what I said a couple of days ago: it's a very bad idea to be
enabling more plpgsql plugins as long as the infrastructure c
Robert Haas writes:
> As far as back-patching the GUCs, my thought would be to back-patch
> them but mark them GUC_NOT_IN_SAMPLE in 9.3, so we don't have to touch
> the default postgresql.conf.
That seems bizarre and pointless.
Keep in mind that 9.3 is still wet behind the ears and many many peo
On 2014-01-04 11:54:46 -0500, Robert Haas wrote:
> On Sat, Jan 4, 2014 at 11:07 AM, Fabrizio Mello
> wrote:
> >> I continue to think that the case for having this feature at all has
> >> not been well-made.
> >
> > We can use this feature to store any custom GUC for relations, attributes
> > and
On Sat, Jan 4, 2014 at 11:07 AM, Fabrizio Mello wrote:
>> I continue to think that the case for having this feature at all has
>> not been well-made.
>
> We can use this feature to store any custom GUC for relations, attributes and
> functions also.
>
> Some use cases:
> * extension options
> * c
Enviado via iPhone
> Em 02/01/2014, às 22:16, Robert Haas escreveu:
>
>> On Thu, Jan 2, 2014 at 4:19 AM, Andres Freund wrote:
>> On 2013-12-31 13:37:59 +0100, Pavel Stehule wrote:
We use the namespace "ext" to the internal code
(src/backend/access/common/reloptions.c) skip some valida
Hello
I am thinking how to implement a assertions and tracking to plpgsql. This
area is not strict and clear - everybody would little bit different
functionality - and implementation can be different if someone use a psql
as main client or some GUI. So I am sceptical to implement assertion
directl
On Fri, Jan 03, 2014 at 04:46:23PM +0100, Florian Weimer wrote:
> On 01/03/2014 04:20 PM, Tom Lane wrote:
>
> >I think Florian has a good point there, and the reason is this: what
> >you are talking about will be of exactly zero use to applications that
> >want to see the results of one query befo
On Fri, Jan 3, 2014 at 9:11 AM, Alvaro Herrera wrote:
> Robert Haas escribió:
>> On Mon, Dec 30, 2013 at 10:59 PM, Alvaro Herrera
>> wrote:
>> > One problem I see is length of time before freezing multis: they live
>> > for far too long, causing the SLRU files to eat way too much disk space.
>> >
On Fri, Jan 3, 2014 at 10:12 AM, Andres Freund wrote:
> On 2013-12-12 10:01:21 -0500, Robert Haas wrote:
>> On Thu, Dec 12, 2013 at 7:04 AM, Andres Freund
>> wrote:
>> > I think there'll always be a bit of a difference between slots for
>> > physical and logical data, even if 90% of the implemen
Hi Magnus,
Il 04/01/14 13:25, Magnus Hagander ha scritto:
> My first reaction was that exactly those two things were missing. And
> then I read your whole email :)
:)
> With those two, I think it would make much sense to have a view like
> this.
Ok, I will prepare version 2 with those.
> I'd s
Presumably "classifyConditions", not "classifyClauses", is meant.
Patch attached.
Regards
Ian Barwick
diff --git a/contrib/postgres_fdw/postgres_fdw.c
b/contrib/postgres_fdw/postgres_fdw.c
index 246a3a9..46ea032 100644
--- a/contrib/postgres_fdw/postgres_fdw.c
+++ b/contrib/postgres_fdw/postgre
On Sat, Jan 4, 2014 at 1:33 AM, Gabriele Bartolini <
gabriele.bartol...@2ndquadrant.it> wrote:
> Hello,
>
> please find attached the patch that adds basic support for the
> pg_stat_archiver system view, which allows users that have continuous
> archiving procedures in place to keep track of some
I am not sure it worth reporting but it took me a while to find out
what is wrong with comparing two values returned from
the bitncmp function. It does not return -1, 1 or 0 as it is written
on the comment when n % 8 == 0.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On 01/04/2014 12:05 PM, David Fetter wrote:
I'm sorry I misunderstood about the extension you wrote.
Is there some way not to use shared memory for it?
No, IMCS ("In-Memory Columnar Store") is storing data in shared memory.
Certainly I could allocate shared memory myself, but due to portabilit
I'm sorry I misunderstood about the extension you wrote.
Is there some way not to use shared memory for it?
Cheers,
David.
On Sat, Jan 04, 2014 at 11:46:25AM +0400, knizhnik wrote:
> Hi David,
>
> Sorry, but I do not completely understand your suggestions:
>
> 1. IMCS really contains single pa
31 matches
Mail list logo
