On tor, 2011-02-03 at 18:36 -0500, Noah Misch wrote:
> Looks good and tests well. I've attached the same benchmark script
> with updated timings, and I've marked the patch Ready for Committer.
Committed. Thanks everyone.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
> o in the recent there are no efforts known to experiment with
> reference types, methods, or rule inference on top of PostgreSQL --
> advice that can be given mostly points to the given documented
> functionality
Correct, AFAIK.
> o extensions of PostgreSQL to support such a kind of usage
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> There is only bad keywords in doc - SCALE instead SLICE and a maybe a
> usage of slicing need a example.
Err, yeah, a couple of stupid documentation issues, sorry about that.
commit 9460c0831f5de71e31823b7e9d8511d2d8124776
Author: Stephen Frost
> This discussion reveals that it's time to start making some
> discussions about what can be accomplished for 9.1 and what must be
> postponed to 9.2. The big ones I think we should postpone are:
First off, I think that this is a little premature. As others have
pointed out, the unusual schedu
Hello,
I am a computer student in belgium, for my academic project I am working to
an extension of postgresql 9 under win xp, by creating h DLL in Visual C++
2008 - I am new in both environments; To start and understand how does it
works, I tried to compile the example complex.c which is in the
dir
Bonjour,
On parle plutôt français sur cette liste d'habitude :)
To reach an English-speaking forum please consider pgsql-general.
michel wildcat writes:
> I am a computer student in belgium, for my academic project I am working to
> an extension of postgresql 9 under win xp, by creating h DLL i
I have gone ahead and committed the core and documentation parts of this
patch, but not as yet any of the contrib changes; that is, all the
contrib modules are still building old-style. I had intended to do it
in two steps all along, so as to get some buildfarm proof for the thesis
that we haven't
* Robert Haas (robertmh...@gmail.com) wrote:
> I think the syntax Tom suggested before was FOREACH thingy IN ARRAY
> arr rather than just FOREACH thingy IN arr. That's probably a good
> idea, because it gives us an escape hatch against needing to invent
> yet another variant of this syntax - the w
Dimitri Fontaine writes:
> Tom Lane writes:
>> 2. Invent a command "ALTER EXTENSION extname ADD object-description"
>> that simply adds a pg_depend entry marking an existing object as
>> belonging to the extension. I think this was going to be part of the
>> plan anyway for ALTER EXTENSION UPGRA
Tom Lane writes:
> I have gone ahead and committed the core and documentation parts of this
Thank you!
And I'd like to take the time to thank all of you who helped me reach
this goal, but that ranges to about everyone here who I talked to at any
conference those last two or three years (I still
Heikki Linnakangas wrote:
> LOG: shmemsize 3153112
> LOG: actual 2339864
>
> Which is a pretty big overestimate, percentage-wise. Taking
> RWConflictPool into account in PredicateLockShmemSize() fixes the
> underestimate, but makes the overestimate correspondingly larger.
> I've never compare
--On 8. Februar 2011 12:24:11 + Simon Riggs
wrote:
Extend ALTER TABLE to allow Foreign Keys to be added without initial
validation. FK constraints that are marked NOT VALID may later be
VALIDATED, which uses an ShareUpdateExclusiveLock on constraint table and
RowShareLock on referenced
Tom Lane writes:
> OK, that seems like an equally reasonable syntax; although doing it the
> way I was thinking might have less of a code and documentation footprint
> (I was vaguely imagining that it could share most of the COMMENT
> infrastructure --- but haven't looked yet). In any case it see
On 8 February 2011 21:08, Peter Eisentraut wrote:
> On tor, 2011-02-03 at 18:36 -0500, Noah Misch wrote:
>> Looks good and tests well. I've attached the same benchmark script
>> with updated timings, and I've marked the patch Ready for Committer.
>
> Committed. Thanks everyone.
Awesome work Pet
On 07/02/11 06:10, Hitoshi Harada wrote:
> 2011/2/7 Jan Urbański :
>> On 04/02/11 16:26, Hitoshi Harada wrote:
>>> 2011/1/28 Jan Urbański :
On 27/01/11 00:41, Jan Urbański wrote:
> I'm also attaching an updated version that should apply on top of my
> github refactor branch (or increme
Dimitri Fontaine writes:
> Tom Lane writes:
>>> [ ALTER object SET EXTENSION versus ALTER EXTENSION ADD object ]
>> OK, that seems like an equally reasonable syntax; although doing it the
>> way I was thinking might have less of a code and documentation footprint
>> (I was vaguely imagining that
Robert Haas wrote:
> On Fri, Feb 4, 2011 at 12:02 PM, Oleg Bartunov wrote:
> > Aha,
> >
> > Teodor sent it to the list Dec 28, see
> > http://archives.postgresql.org/message-id/4D1A1677.80300%40sigaev.ru
> >
> > After a month I didn't see any activity on this patch, so I I added it to
> > https://
On Tue, 2011-02-08 at 22:58 +0100, Bernd Helmle wrote:
>
> --On 8. Februar 2011 12:24:11 + Simon Riggs
> wrote:
>
> > Extend ALTER TABLE to allow Foreign Keys to be added without initial
> > validation. FK constraints that are marked NOT VALID may later be
> > VALIDATED, which uses an Share
Dimitri Fontaine writes:
> Tom Lane writes:
>> (I was vaguely imagining that it could share most of the COMMENT
>> infrastructure --- but haven't looked yet).
> Well the code footprint is quite small already.
Having now looked at it a bit closer, I think the syntax choice is a
complete wash fro
On Tue, Feb 08, 2011 at 04:04:39PM -0600, Kevin Grittner wrote:
> (2) The predicate lock and lock target initialization code was
> initially copied and modified from the code for heavyweight locks.
> The heavyweight lock code adds 10% to the calculated maximum size.
> So I wound up doing that fo
On Tue, 2011-02-08 at 14:25 -0500, Robert Haas wrote:
> > The patch is a million little decisions: names, catalog structure,
> > interface, representation, general usability, grammar, functionality,
> > etc. Without some checkpoint, the chances that everyone agrees with all
> > of these decisions a
On 02/07/2011 06:38 AM, Thom Brown wrote:
On 7 February 2011 09:04, Itagaki Takahiro wrote:
On Fri, Feb 4, 2011 at 21:32, Thom Brown wrote:
The issue is that generate_series will not return if the series hits
either the upper or lower boundary during increment, or goes beyond
it. The attac
On Wed, Feb 9, 2011 at 10:17, Andrew Dunstan wrote:
> Isn't this all really a bug fix that should be backpatched, rather than a
> commitfest item?
Sure, but we don't have any bug trackers...
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
On 02/08/2011 08:19 PM, Itagaki Takahiro wrote:
On Wed, Feb 9, 2011 at 10:17, Andrew Dunstan wrote:
Isn't this all really a bug fix that should be backpatched, rather than a
commitfest item?
Sure, but we don't have any bug trackers...
Quite right, but the commitfest manager isn't meant to
On Tue, Feb 8, 2011 at 13:34, Robert Haas wrote:
> So how close are we to having a committable version of this? Should
> we push this out to 9.2?
I think so. The feature is pretty attractive, but more works are required:
* Re-base on synchronized snapshots patch
* Consider to use pipe also on
On 02/07/2011 11:30 PM, Robert Haas wrote:
On Tue, Dec 28, 2010 at 9:23 PM, Karl Lehenbauer
wrote:
On Dec 28, 2010, at 7:29 PM, Tom Lane wrote:
This patch appears to be changing a whole lot of stuff that in fact
pg_indent has never changed, so there's something wrong with the way you
are do
On Tue, Feb 8, 2011 at 10:33, Alex Hunsaker wrote:
> On Tue, Feb 8, 2011 at 08:18, Alexey Klyukin wrote:
>>
>> On Feb 6, 2011, at 9:43 AM, Alex Hunsaker wrote:
>
>>> So here is a v6
>>>
>>> Comments?
>>
>> Thanks, looks great to me. It passes all the tests on my OS X system. I
>> wonder
>>
On Mon, Feb 7, 2011 at 22:47, Heikki Linnakangas
wrote:
> On Mon, Feb 7, 2011 at 21:17, Noah Misch wrote:
>> The message does not show which foreign table yielded the error. We could
>> evade
>> the problem in this case by adding a file name to the error message in the
>> COPY
>> code,
> Yeah
On Tue, Feb 8, 2011 at 6:54 PM, Tom Lane wrote:
> Dimitri Fontaine writes:
>> Tom Lane writes:
>>> (I was vaguely imagining that it could share most of the COMMENT
>>> infrastructure --- but haven't looked yet).
>
>> Well the code footprint is quite small already.
>
> Having now looked at it a b
On Tue, Feb 8, 2011 at 7:23 PM, Dan Ports wrote:
> On Tue, Feb 08, 2011 at 04:04:39PM -0600, Kevin Grittner wrote:
>> (2) The predicate lock and lock target initialization code was
>> initially copied and modified from the code for heavyweight locks.
>> The heavyweight lock code adds 10% to the c
On Tue, Feb 8, 2011 at 8:30 PM, Andrew Dunstan wrote:
> Quite right, but the commitfest manager isn't meant to be a substitute for
> one. Bug fixes aren't subject to the same restrictions of feature changes.
Another option would be to add this here:
http://wiki.postgresql.org/wiki/PostgreSQL_9.1
Robert Haas writes:
> On Tue, Feb 8, 2011 at 6:54 PM, Tom Lane wrote:
>> Having now looked at it a bit closer, I think the syntax choice is a
>> complete wash from an implementation standpoint: either way, we'll have
>> a list of bison productions that build AlterObjectExtensionStmt nodes,
>> and
Robert Haas writes:
> ... And you could even allow multiple objects:
> ALTER EXTENSION extension_name ADD object-description [, ...];
> Which might be handy.
I just thought of a different way of coming at the question, which might
help us make a choice.
Like ALTER THING SET SCHEMA, ALTER THING S
On Tue, Feb 8, 2011 at 9:48 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... And you could even allow multiple objects:
>> ALTER EXTENSION extension_name ADD object-description [, ...];
>> Which might be handy.
>
> I just thought of a different way of coming at the question, which might
> help us
2011/2/9 Jan Urbański :
> I hope this version does the right thing, while still avoiding the
> performance hit of looking up I/O funcs every time a row is returned.
> Actually, PL/Perl *does* look up the I/O funcs every time, so in the
> worst case I can just drop this optimisation. But let's hope
Robert Haas writes:
> On Tue, Feb 8, 2011 at 9:48 PM, Tom Lane wrote:
>> Like ALTER THING SET SCHEMA, ALTER THING SET EXTENSION is implicitly
>> assuming that there can be only one owning extension for an object.
> I would assume that we would enforce that constraint anyway. No?
> Otherwise whe
On Tue, Feb 8, 2011 at 10:25 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Feb 8, 2011 at 9:48 PM, Tom Lane wrote:
>>> Like ALTER THING SET SCHEMA, ALTER THING SET EXTENSION is implicitly
>>> assuming that there can be only one owning extension for an object.
>
>> I would assume that we w
Robert Haas writes:
> On Tue, Feb 8, 2011 at 10:25 PM, Tom Lane wrote:
>> My point is that the current restriction to just one containing
>> extension seems to me to be an implementation restriction, rather than
>> something inherent in the concept of extensions. I have no intention of
>> trying
On Wed, Feb 9, 2011 at 3:30 AM, Simon Riggs wrote:
> Basic Recovery Control functions for use in Hot Standby. Pause, Resume,
> Status check functions only. Also, new recovery.conf parameter to
> pause_at_recovery_target, default on.
Why did you change the default to on? This would surprise people
2010/12/31 Jan Urbański :
> (continuing the flurry of patches)
>
> Here's a patch that stops PL/Python from removing the function's
> arguments from its globals dict after calling it. It's
> an incremental patch on top of the plpython-refactor patch sent in
> http://archives.postgresql.org/message-
On Tue, Feb 8, 2011 at 8:31 PM, Itagaki Takahiro
wrote:
> On Tue, Feb 8, 2011 at 13:34, Robert Haas wrote:
>> So how close are we to having a committable version of this? Should
>> we push this out to 9.2?
>
> I think so. The feature is pretty attractive, but more works are required:
> * Re-bas
On Wed, 2011-02-09 at 12:50 +0900, Fujii Masao wrote:
> On Wed, Feb 9, 2011 at 3:30 AM, Simon Riggs wrote:
> > Basic Recovery Control functions for use in Hot Standby. Pause, Resume,
> > Status check functions only. Also, new recovery.conf parameter to
> > pause_at_recovery_target, default on.
>
On Tue, Feb 08, 2011 at 09:09:48PM -0500, Robert Haas wrote:
> No way to fail is a tall order.
Well, no way to fail due to running out of shared memory in
RegisterPredicateLock/RegisterPredicateLockingXid, but that doesn't
have quite the same ring to it...
> If we don't allocate all the memory up
On Tue, 2011-02-08 at 09:10 -0800, Jeff Davis wrote:
> On Mon, 2011-02-07 at 18:23 +0100, Dimitri Fontaine wrote:
> > I would think
> >
> > CREATE TYPE foo AS RANGE (bar) USING (btree_ops);
> >
> > The USING clause is optional, because you generally have a default btree
> > opclass for the data
There are two issues I'd like to discuss related to constructing range
types from other values.
1.
The obvious constructor would be:
range(1, 10)
But is that [1, 10), (1, 10], (1, 10), or [1, 10]? We need to support
all 4, and it's not obvious how to do that easily. The solution that I
came up
On Tue, 2011-02-08 at 20:43 +0100, Erik Rijkers wrote:
> --
> Documentation:
> --
>
> Section 9.18:
> table 9-42. range functions:
> The following functions are missing (I encountered them in the regression
> tests):
> contained_by()
> range_eq()
I opted not t
On Wed, Feb 9, 2011 at 4:53 AM, Simon Riggs wrote:
> Committed. Thanks for the patch and the review.
- * We also track the timestamp of the latest applied COMMIT/ABORT record
- * in XLogCtl->recoveryLastXTime, for logging purposes.
+ * We also track the timestamp of the latest applied COMMIT/ABOR
On Wed, Feb 9, 2011 at 2:02 PM, Simon Riggs wrote:
>> Why did you change the default to on? This would surprise people who are
>> used to PITR.
>
> You pointed out that the code did not match the documented default. So I
> made them match according to the docs.
Well, I meant changing the docs rat
On Wed, Feb 9, 2011 at 14:50, Jeff Davis wrote:
> 1.
> The obvious constructor would be:
> range(1, 10)
> But is that [1, 10), (1, 10], (1, 10), or [1, 10]? We need to support
> all 4, and it's not obvious how to do that easily.
here is the same issue in table partitioning. Also, We might use th
On Wed, Feb 09, 2011 at 02:55:26PM +0900, Itagaki Takahiro wrote:
> On Wed, Feb 9, 2011 at 03:49, Noah Misch wrote:
> > The code still violates the contract of ExecEvalExpr() by calling it with
> > CurrentMemoryContext != econtext->ecxt_per_tuple_memory.
>
> I'm not sure whether we have such cont
On Wed, 2011-02-09 at 15:39 +0900, Itagaki Takahiro wrote:
> On Wed, Feb 9, 2011 at 14:50, Jeff Davis wrote:
> > 1.
> > The obvious constructor would be:
> > range(1, 10)
> > But is that [1, 10), (1, 10], (1, 10), or [1, 10]? We need to support
> > all 4, and it's not obvious how to do that easil
101 - 151 of 151 matches
Mail list logo
