I think the v5 patch should be marked as 'Ready for Committer'
2011/6/18 Josh Kupershmidt :
> On Sat, Jun 18, 2011 at 10:53 AM, Kohei KaiGai wrote:
>> In addition, this pg_comments system view supports 'access method' class, but
>> we cannot set a comment on access methods using COMMENT ON statem
Thanks for your review.
2011/6/19 Robert Haas :
> On Tue, Jun 14, 2011 at 8:06 AM, Kohei KaiGai wrote:
>> The attached patch is a preparation to rework implementation of DROP
>> statement
>> using a common code. That intends to apply get_object_address() to resolve
>> name
>> of objects to be r
On Jun19, 2011, at 00:23 , Jeff Davis wrote:
> On Sat, 2011-06-18 at 22:19 +0200, Florian Pflug wrote:
>> Yes, that seems necessary for consistency. That leaves the question
>> of what to do if someone tries to modify a textrange's collation with
>> a COLLATE clause. For example,
>>
>> For example
I want to implement hugepages for shared memory, to make it transparent I want
to do in this fashion:
1. Reserve memory M of size s
2. Try to allocate hugepage memory of as big size as possible (hs), attach at
M.
3. Allocate normal shared memory of size hs - s, and attach it at M+hs.
This souluti
On Sun, Jun 19, 2011 at 11:56:15AM +0200, Rados??aw Smogura wrote:
> I want to implement hugepages for shared memory, to make it transparent I
> want
> to do in this fashion:
> 1. Reserve memory M of size s
> 2. Try to allocate hugepage memory of as big size as possible (hs), attach at
> M.
> 3.
Martijn van Oosterhout Sunday 19 of June 2011 12:35:18
> On Sun, Jun 19, 2011 at 11:56:15AM +0200, Rados??aw Smogura wrote:
> > I want to implement hugepages for shared memory, to make it transparent I
> > want to do in this fashion:
> > 1. Reserve memory M of size s
> > 2. Try to allocate hugepag
On Sun, Jun 19, 2011 at 11:21:28AM +0200, Florian Pflug wrote:
> > I think rejecting it makes more sense, so a range would not be a
> > collatable type; it just happens to use collations of the subtype
> > internally.
>
> Ah, crap, I put the COLLATE in the wrong place. What I actually
> had in min
Hello
2011/6/19 Steve Singer :
> On 11-06-08 04:14 PM, Pavel Stehule wrote:
>>
>> Hello
>>
>> Attached patch implements a new erros's fields that describes table,
>> colums related to error. This enhanced info is limited to constraints
>> and RI.
>>
>
...
>
> I think that both the CONSTRAINT, an
2011/6/19 Steve Singer :
> On 11-06-18 06:36 PM, Steve Singer wrote:
>>
>> On 11-06-08 04:14 PM, Pavel Stehule wrote:
>>
>> Here is my review of this patch
>>
>> Submission Review:
>>
>> The patch applies cleanly against master
>> The patch does not include any documentatio
2011/6/19 Robert Haas :
> On Sat, Jun 18, 2011 at 9:21 AM, Pavel Stehule
> wrote:
>> Is this profile expected?
>
> I've certainly seen profiles before where the catcache overhead was
> significant. I don't think that I've seen SearchCatCache() quite this
> high on any of the profiling I've done,
On Sat, Jun 18, 2011 at 11:32:20PM -0400, Robert Haas wrote:
> On Sat, Jun 18, 2011 at 11:12 PM, Robert Haas wrote:
> > On Sat, Jun 18, 2011 at 11:06 PM, Noah Misch wrote:
> >> On Sat, Jun 18, 2011 at 10:57:13PM -0400, Robert Haas wrote:
> >>> On Sat, Jun 11, 2011 at 5:13 PM, Noah Misch wrote:
>
2011/6/19 Pavel Stehule :
> 2011/6/19 Robert Haas :
>> On Sat, Jun 18, 2011 at 9:21 AM, Pavel Stehule
>> wrote:
>>> Is this profile expected?
>>
>> I've certainly seen profiles before where the catcache overhead was
>> significant. I don't think that I've seen SearchCatCache() quite this
>> high
Sorry, the previous revision did not update regression test part
towards the latest one.
2011/6/19 Kohei KaiGai :
> Thanks for your review.
>
> 2011/6/19 Robert Haas :
>> On Tue, Jun 14, 2011 at 8:06 AM, Kohei KaiGai wrote:
>>> The attached patch is a preparation to rework implementation of DROP
On Jun19, 2011, at 05:10 , Steve Singer wrote:
> On 11-06-18 06:36 PM, Steve Singer wrote:
>> On 11-06-08 04:14 PM, Pavel Stehule wrote:
>>
>> Here is my review of this patch
>>
>> Submission Review:
>>
>> The patch applies cleanly against master
>> The patch does not inc
Tom Lane wrote:
> Bruce Momjian writes:
> > Perhaps we should recommend:
> > cd /path && test ! -f %f && cp %p %f
> > That is shorter and removes the duplicate problem.
>
> Um ... %p is relative to the database directory.
Oh, I see now. I had thought it was an absolute path, but good thing
2011/6/19 Florian Pflug :
> On Jun19, 2011, at 05:10 , Steve Singer wrote:
>> On 11-06-18 06:36 PM, Steve Singer wrote:
>>> On 11-06-08 04:14 PM, Pavel Stehule wrote:
>>>
>>> Here is my review of this patch
>>>
>>> Submission Review:
>>>
>>> The patch applies cleanly agains
On Jun19, 2011, at 14:03 , Pavel Stehule wrote:
> 2011/6/19 Florian Pflug :
>> Speaking as someone who's wished for the feature that Pavel's patch provides
>> many times in the past - shouldn't there also be a field containing the
>> offending value? If we had that, it'd finally be possible to tran
On 06/19/2011 08:00 AM, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian writes:
Perhaps we should recommend:
cd /path&& test ! -f %f&& cp %p %f
That is shorter and removes the duplicate problem.
Um ... %p is relative to the database directory.
Oh, I see now. I had thought it
On Tue, Jun 14, 2011 at 4:04 PM, Robert Haas wrote:
> 1. ANALYZE happens far too infrequently to believe that any data taken
> at ANALYZE time will still be relevant at execution time.
> 2. Using data gathered by ANALYZE will make plans less stable, and our
> users complain not infrequently about
On Thu, Jun 16, 2011 at 6:11 AM, Tom Lane wrote:
> (I will refrain for
> the moment from speculating whether we'll ever have an index type that
> supports regexp match directly as an indexable operator...)
Fwiw I looked into this at one point and have some ideas if anyone is
keen to try it.
--
2011/6/19 Florian Pflug :
> On Jun19, 2011, at 14:03 , Pavel Stehule wrote:
>> 2011/6/19 Florian Pflug :
>>> Speaking as someone who's wished for the feature that Pavel's patch provides
>>> many times in the past - shouldn't there also be a field containing the
>>> offending value? If we had that,
Hi
It looks like we've failed to reach an agreement on how to
proceed on the issue with missing commutators for the various
text matching operators ("~", "~~", and their case-insensitive
variants). We do seem to have agreed, however, that adding
commutators for the non-deprecated operators which l
2011/6/19 Greg Stark :
> On Tue, Jun 14, 2011 at 4:04 PM, Robert Haas wrote:
>> 1. ANALYZE happens far too infrequently to believe that any data taken
>> at ANALYZE time will still be relevant at execution time.
>> 2. Using data gathered by ANALYZE will make plans less stable, and our
>> users com
2011/6/17 Andrew Tipton :
> On Fri, Jun 10, 2011 at 22:16, Hitoshi Harada wrote:
>>
>> Isn't it worth adding new consistent function for those purposes? The
>> approach in the patch as stands looks kludge to me.
>
> Thanks for your review. Coming back to this patch after a few months'
> time, I h
2011/5/14 Robert Haas :
> On Fri, May 13, 2011 at 6:34 PM, Cédric Villemain
> wrote:
>> If reviewers agree it is safe and benchmarks make evidences that no
>> basic performance issue are raised, then let's see if next items have
>> blockers or can be done.
>
> Sounds right to me.
and recent stuf
2011/5/11 Bruce Momjian :
> Cédric Villemain wrote:
>> 2011/5/10 Kevin Grittner :
>> > Simon Riggs wrote:
>> >> The typical speed up for non-covered indexes will come when we
>> >> access a very large table (not in cache) via an index scan that is
>> >> smaller than a bitmapindex scan. Will we be
On Sun, Jun 19, 2011 at 3:25 AM, Kohei KaiGai wrote:
> 2011/6/18 Josh Kupershmidt :
> I think the v5 patch should be marked as 'Ready for Committer'
I think we still need to handle my "Still TODO" concerns noted
upthread. I don't have a lot of time this weekend due to a family
event, but I was mu
On Sat, Jun 18, 2011 at 10:18:50PM +, Peter Eisentraut wrote:
> Make external_pid_file world readable
Should this be back-patched?
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
Robert Haas wrote:
> Kevin Grittner wrote:
>> I'm certainly open to suggestions for better wording.
> How about something like this:
>
> When the system is forced to combine multiple page-level predicate
> locks into a single relation-level predicate lock because the
> predicate lock table i
I am wondering If I am missing something obvious. If not, I have a suggestion
for plpgsql.
Stored procedures can accept rows.
Libpq can receive rows (PQResult).
Wouldn't it be a great interface if PQResult was "bi-directional"? Create a
result set on the client then call the database with a com
I took another look at this this evening, and realised that my
comments could be a little clearer.
Attached revision cleans them up a bit.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
diff --git a/src/backend/access/transam/xlog
On 6/19/2011 11:04 AM, Jeff Shanab wrote:
I am wondering If I am missing something obvious. If not, I have a suggestion
for plpgsql.
Stored procedures can accept rows.
Libpq can receive rows (PQResult).
Wouldn’t it be a great interface if PQResult was “bi-directional”? Create a
result set on t
On Mon, 2011-06-06 at 14:03 -0400, Robert Haas wrote:
> The attached patch refactors heap_hot_search_buffer() so that
> index_getnext() can use it, and modifies index_getnext() to do so.
Attached is a version of the patch that applies cleanly to master.
Regards,
Jeff Davis
heap-hot-sear
On Sun, 2011-06-19 at 10:50 -0700, Jeff Davis wrote:
> On Mon, 2011-06-06 at 14:03 -0400, Robert Haas wrote:
> > The attached patch refactors heap_hot_search_buffer() so that
> > index_getnext() can use it, and modifies index_getnext() to do so.
>
> Attached is a version of the patch that applies
On Sun, 2011-06-19 at 12:24 +0200, Martijn van Oosterhout wrote:
> Collation checking is generally done by the planner. I don't see why
> the input function should check, the result of an input function is by
> definition DEFAULT. It's up to the 'in' operator to check.
>
> Note that the whole idea
On Sun, Jun 19, 2011 at 2:01 PM, Jeff Davis wrote:
> On Sun, 2011-06-19 at 10:50 -0700, Jeff Davis wrote:
>> On Mon, 2011-06-06 at 14:03 -0400, Robert Haas wrote:
>> > The attached patch refactors heap_hot_search_buffer() so that
>> > index_getnext() can use it, and modifies index_getnext() to do
On Sun, Jun 19, 2011 at 10:44 AM, Cédric Villemain
wrote:
> and recent stuff on VM will allow us to move forward it seems !
Yep, looks promising. The heap_hot_search_buffer refactoring patch is
related as well.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
Robert Haas writes:
> Yikes. I think you are right. It's kind of scary that the regression
> tests passed with that mistake.
Can we add a test that exposes that mistake?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
On Sun, Jun 19, 2011 at 11:12 AM, Cédric Villemain
wrote:
>> Good point --- we would be making plan decisions based on the visibility
>> map coverage. The big question is whether visibility map changes are
>> more dynamic than the values we already plan against, like rows in the
>> table, table s
On Sun, Jun 19, 2011 at 2:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> Yikes. I think you are right. It's kind of scary that the regression
>> tests passed with that mistake.
>
> Can we add a test that exposes that mistake?
Not sure. We'd have to figure out how to reliably tickle it.
--
On Sun, Jun 19, 2011 at 9:38 AM, Greg Stark wrote:
> On Tue, Jun 14, 2011 at 4:04 PM, Robert Haas wrote:
>> 1. ANALYZE happens far too infrequently to believe that any data taken
>> at ANALYZE time will still be relevant at execution time.
>> 2. Using data gathered by ANALYZE will make plans less
On Sun, Jun 19, 2011 at 9:53 AM, Florian Pflug wrote:
> Amidst the discussion, Alvaro suggested that we resolve the issue
> by adding a distinct type for patterns as opposed to text. That'd
> allow us to make "~" it's own commutator by defining both
> text ~ pattern
> and
> pattern ~ text.
That
2011/6/19 Robert Haas :
> On Sun, Jun 19, 2011 at 11:12 AM, Cédric Villemain
> wrote:
>>> Good point --- we would be making plan decisions based on the visibility
>>> map coverage. The big question is whether visibility map changes are
>>> more dynamic than the values we already plan against, lik
On Jun19, 2011, at 20:56 , Robert Haas wrote:
> On Sun, Jun 19, 2011 at 9:53 AM, Florian Pflug wrote:
>> Amidst the discussion, Alvaro suggested that we resolve the issue
>> by adding a distinct type for patterns as opposed to text. That'd
>> allow us to make "~" it's own commutator by defining bo
Martijn van Oosterhout writes:
> On Sun, Jun 19, 2011 at 11:56:15AM +0200, Rados??aw Smogura wrote:
>> I want to implement hugepages for shared memory, to make it transparent I
>> want
> At least in Linux they're trying to make hugepages transparent, so I'm
> wondering if this is going to make
On Jun19, 2011, at 20:08 , Jeff Davis wrote:
> On Sun, 2011-06-19 at 12:24 +0200, Martijn van Oosterhout wrote:
>> Collation checking is generally done by the planner. I don't see why
>> the input function should check, the result of an input function is by
>> definition DEFAULT. It's up to the 'in
2011/6/19 Robert Haas :
> On Sun, Jun 19, 2011 at 9:38 AM, Greg Stark wrote:
>> On Tue, Jun 14, 2011 at 4:04 PM, Robert Haas wrote:
>>> 1. ANALYZE happens far too infrequently to believe that any data taken
>>> at ANALYZE time will still be relevant at execution time.
>>> 2. Using data gathered b
On Sun, Jun 19, 2011 at 02:48:58PM +0100, Greg Stark wrote:
> On Thu, Jun 16, 2011 at 6:11 AM, Tom Lane wrote:
> > (I will refrain for the moment from speculating whether we'll ever
> > have an index type that supports regexp match directly as an
> > indexable operator...)
>
> Fwiw I looked into
I hope this hasn't been forgotten. But I cant see it has been committed
or moved
into the commitfest process?
Jesper
On 2011-03-11 16:51, Noah Misch wrote:
On Fri, Feb 11, 2011 at 02:13:22AM -0500, Noah Misch wrote:
Automated tests would go a long way toward building confidence that this pat
Hey Jeff,
2011/6/19 Jeff Shanab
> I am wondering If I am missing something obvious. If not, I have a
> suggestion for plpgsql.
>
> ** **
>
> Stored procedures can accept rows.
>
> Libpq can receive rows (PQResult).
>
> ** **
>
> Wouldn’t it be a great interface if PQResult was “bi-di
On 06/19/2011 02:56 PM, Robert Haas wrote:
On Sun, Jun 19, 2011 at 9:53 AM, Florian Pflug wrote:
Amidst the discussion, Alvaro suggested that we resolve the issue
by adding a distinct type for patterns as opposed to text. That'd
allow us to make "~" it's own commutator by defining both
text
Andrew Dunstan writes:
> On 06/19/2011 02:56 PM, Robert Haas wrote:
>> On Sun, Jun 19, 2011 at 9:53 AM, Florian Pflug wrote:
>>> Amidst the discussion, Alvaro suggested that we resolve the issue
>>> by adding a distinct type for patterns as opposed to text. That'd
>>> allow us to make "~" it's ow
On sön, 2011-06-19 at 08:59 -0700, David Fetter wrote:
> On Sat, Jun 18, 2011 at 10:18:50PM +, Peter Eisentraut wrote:
> > Make external_pid_file world readable
>
> Should this be back-patched?
I wasn't planning to. It's a new feature.
--
Sent via pgsql-hackers mailing list (pgsql-hacker
On Sun, Jun 19, 2011 at 2:41 PM, Robert Haas wrote:
> On Sun, Jun 19, 2011 at 2:20 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Yikes. I think you are right. It's kind of scary that the regression
>>> tests passed with that mistake.
>>
>> Can we add a test that exposes that mistake?
>
> Not
On Jun19, 2011, at 22:10 , Tom Lane wrote:
> Andrew Dunstan writes:
>> On 06/19/2011 02:56 PM, Robert Haas wrote:
>>> On Sun, Jun 19, 2011 at 9:53 AM, Florian Pflug wrote:
Amidst the discussion, Alvaro suggested that we resolve the issue
by adding a distinct type for patterns as opposed
On Jun19, 2011, at 20:40 , Robert Haas wrote:
> 2. Since VACUUM and ANALYZE often run together, we will be estimating
> the percentage of rows on all-visible pages just at the time when that
> percentage is highest. This is not exactly wonderful, either...
Hm, doesn't autovacuum run ANALYZE quite
On Fri, Jun 17, 2011 at 11:41 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 16, 2011 at 6:54 PM, Tom Lane wrote:
>>> 4. Backend #2 visits the new, about-to-be-committed version of
>>> pgbench_accounts' pg_class row just before backend #3 commits.
>>> It sees the row as not good and ke
On Sun, Jun 19, 2011 at 5:10 PM, Florian Pflug wrote:
> On Jun19, 2011, at 20:40 , Robert Haas wrote:
>> 2. Since VACUUM and ANALYZE often run together, we will be estimating
>> the percentage of rows on all-visible pages just at the time when that
>> percentage is highest. This is not exactly wo
On 06/19/2011 09:38 AM, Greg Stark wrote:
There's another problem which I haven't seen mentioned. Because the
access method will affect the cache there's the possibility of
feedback loops. e.g. A freshly loaded system prefers sequential scans
for a given table because without the cache the seeks
Greg Smith wrote:
> I'm not too concerned about the specific case you warned about
> because I don't see how sequential scan vs. index costing will be
> any different on a fresh system than it is now.
I think the point is that if, on a fresh system, the first access to
a table is something whi
I applied Jeff's patch but changed this to address concerns about the
program getting stuck running for too long in the function:
#define plpgsql_loops 512
This would be better named as "plpgsql_batch_size" or something similar
instead, the current name suggests it's how many loops to run wh
So I was the victim assigned to review this patch.
The code is pretty much impeccable as usual from Noah. But I have
questions about the semantics of it.
Firstly this bit makes me wonder:
+ /* Not-found is always final. */
+ if (!OidIsValid(relOid1))
+
On 06/19/2011 05:02 PM, Florian Pflug wrote:
On Jun19, 2011, at 22:10 , Tom Lane wrote:
Andrew Dunstan writes:
On 06/19/2011 02:56 PM, Robert Haas wrote:
On Sun, Jun 19, 2011 at 9:53 AM, Florian Pflug wrote:
Amidst the discussion, Alvaro suggested that we resolve the issue
by adding a di
Heikki Linnakangas wrote:
> * The oldserxid code is broken for non-default BLCKSZ.
> o The warning will come either too early or too late
> o There is no safeguard against actually wrapping around the
> SLRU, just the warning
> o I'm suspicious of the OldSerXidPagePrecedesLogically() logic
> with
On Jun20, 2011, at 00:56 , Andrew Dunstan wrote:
> On 06/19/2011 05:02 PM, Florian Pflug wrote:
>> The only argument against that I can see is that it poses
>> a compatibility problem if "~" remains the pattern matching
>> operator. I do believe, however, that the chance of
>> unknown ~ unknown
>
On Jun19, 2011, at 23:16 , Robert Haas wrote:
> On Sun, Jun 19, 2011 at 5:10 PM, Florian Pflug wrote:
>> On Jun19, 2011, at 20:40 , Robert Haas wrote:
>>> 2. Since VACUUM and ANALYZE often run together, we will be estimating
>>> the percentage of rows on all-visible pages just at the time when tha
On 06/19/2011 06:15 PM, Kevin Grittner wrote:
I think the point is that if, on a fresh system, the first access to
a table is something which uses a tables scan -- like select count(*)
-- that all indexed access would then tend to be suppressed for that
table. After all, for each individual que
On Sun, Jun 19, 2011 at 7:59 PM, Florian Pflug wrote:
> On Jun19, 2011, at 23:16 , Robert Haas wrote:
>> On Sun, Jun 19, 2011 at 5:10 PM, Florian Pflug wrote:
>>> On Jun19, 2011, at 20:40 , Robert Haas wrote:
2. Since VACUUM and ANALYZE often run together, we will be estimating
the perc
On Sun, Jun 19, 2011 at 3:32 PM, Cédric Villemain
wrote:
> 2nd, I provided the patches on the last CF, exactly to allow to go to
> the exciting part: the cost-estimates changes. (after all, we can work
> on the cost estimate, and if later we find a way to use ALTER TABLE or
> pg_class_ng, just do
On Sun, Jun 19, 2011 at 11:04 AM, Jeff Shanab wrote:
> I am wondering If I am missing something obvious. If not, I have a
> suggestion for plpgsql.
>
> Stored procedures can accept rows.
>
> Libpq can receive rows (PQResult).
>
> Wouldn’t it be a great interface if PQResult was “bi-directional”? C
On Sat, Jun 18, 2011 at 11:57 AM, Rémi Zara wrote:
> Pika failed at the isolationCheck phase, hitting an assertion:
>
> TRAP: FailedAssertion("!(!((oldSerXidControl->tailXid) != ((TransactionId)
> 0)) || TransactionIdFollows(xid, oldSerXidControl->tailXid))", File:
> "predicate.c", Line: 991)
>
On Fri, Jun 17, 2011 at 3:49 PM, Florian Pflug wrote:
>> The regex is always to the right of the operator.
>
> Which is something you have to remember... It's not in any
> way deducible from "foo ~ bar" alone.
Except that it's always been this way, going back to perl4 or tcl or
their predecessors
On Thu, Jun 16, 2011 at 9:00 PM, Tom Lane wrote:
> BTW, if you're hacking Postgres code and don't already have a
> "reinstall" script, you need one. Mine is basically
>
> pg_ctl stop
> cd $PGBLDROOT/src/backend
> make install-bin
> pg_ctl start
I've always wondered wh
On Sat, Jun 18, 2011 at 10:19 PM, Tom Lane wrote:
> Thom Brown writes:
>> On 18 June 2011 04:13, Bruce Momjian wrote:
>>> I tested on FreeBSD 7.4 and saw a 1 error return:
>
>> And on a Mac (so through Darwin 10.7.0 a BSD version too):
>
> Yeah, see yesterday's discussion on pgsql-admin. I thin
On Fri, Jun 17, 2011 at 11:34 AM, Robert Haas wrote:
> On Thu, Jun 16, 2011 at 10:10 PM, Fujii Masao wrote:
According to the above page, one purpose of time-delayed replication is to
protect against user mistakes on master. But, when an user notices his
wrong
operation on mas
On Sun, 19 Jun 2011, Pavel Stehule wrote:
Maybe there is second issue (little bit - performance - you have to
call a output function), But I agree, so this information is very
interesting and can help.
I am concerned about the performance impact of doing that. Not all
constraints are on int4
Hi Greg,
On Sun, Jun 19, 2011 at 11:44:35PM +0100, Greg Stark wrote:
> So I was the victim assigned to review this patch.
Thanks for doing so.
> The code is pretty much impeccable as usual from Noah. But I have
> questions about the semantics of it.
>
> Firstly this bit makes me wonder:
>
> +
Excerpts from Pavel Stehule's message of dom jun 19 06:51:13 -0400 2011:
> Hello
>
> 2011/6/19 Steve Singer :
> > On 11-06-08 04:14 PM, Pavel Stehule wrote:
> > nbtinsert.c
> >
> > pg_get_indrelation is named differently than everything else in this file
> > (ie _bt...). My guess is that this fu
Greg Stark wrote:
I've always wondered what other people do to iterate quickly.
I'd have bet money you had an elisp program for this by now!
The peg utility script I use makes a reinstall as simple as:
stop
peg build
The UI for peg is still is a little rough around switching to another
proj
On Mon, Jun 20, 2011 at 07:30, Greg Smith wrote:
> I applied Jeff's patch but changed this to address concerns about the
> program getting stuck running for too long in the function:
>
> #define plpgsql_loops 512
Is it OK to define the value as constant?
Also, it executes much more queries if
On Mon, Jun 20, 2011 at 1:00 AM, Peter Geoghegan wrote:
> I took another look at this this evening, and realised that my
> comments could be a little clearer.
>
> Attached revision cleans them up a bit.
Since I'm not familiar with Windows, I haven't read the code related
to Windows. But
the follo
On Sun, 2011-06-19 at 21:29 +0200, Florian Pflug wrote:
> If I'm not mistaken about this, that would imply that we also cannot
> have two range types with the same base type, the same opclass,
> but different collations. Which seems rather unfortunate... In fact,
> if that's true, maybe restricing
82 matches
Mail list logo
