Hi,
On Thu, Nov 12, 2009 at 4:32 PM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>> The problem is that fsync needs to be issued too frequently, which would
>> be harmless in asynchronous replication, but not in synchronous one.
>> A transaction would have to wait for the primary's and standby
On Thu, 2009-11-12 at 17:03 +0900, Fujii Masao wrote:
> On Thu, Nov 12, 2009 at 4:32 PM, Heikki Linnakangas
> wrote:
> > Fujii Masao wrote:
> >> The problem is that fsync needs to be issued too frequently, which would
> >> be harmless in asynchronous replication, but not in synchronous one.
> >>
On Tue, 2009-10-27 at 13:55 +0900, Itagaki Takahiro wrote:
> Here is a patch to support "rewrite" version of VACUUM FULL.
> It was called "VACUUM REWRITE" in the past disucussin,
> but I choose the following syntax for now:
>
> VACUUM ( FULL [ INPLACE | REPLACE ] ) [ table_name ]
>
> The rea
On Sun, 2009-11-08 at 20:52 -0500, Robert Haas wrote:
> I would personally prefer not to be involved in the management of the
> next CommitFest. Having done all of the July CommitFest and a good
> chunk of the September CommitFest, I am feeling a bit burned out.
You did a grand job and everybody
Alvaro Herrera írta:
> Boszormenyi Zoltan escribió:
>
>
>> I have split up (and cleaned up a little) the dynamic
>> cursorname patch into smaller logical, easier-to-review
>> pieces. Descriptions below.
>>
>> 1) 1a-unified-optfromin-fetch-ctxdiff.patch
>>
>> ecpg supports optional FROM/IN in FET
Alvaro Herrera írta:
> Boszormenyi Zoltan escribió:
>
>
>> 2) 1b-cursor_name-ctxdiff.patch
>>
>> "name" -> "cursor_name" transition in core grammar
>> and ecpg grammar. Currently it does nothing, it's a
>> preparation phase. Depends on patch 1.
>>
>
> Applied this part too.
>
> I cannot app
On Thu, Nov 12, 2009 at 2:12 AM, Andrew Gierth
wrote:
> Does it cope with the case where a trigger is doing NOTIFY, and you do
> a whole-table update, therefore dumping potentially millions of
> notifications in at once?
>
> (for example a rare maintenance operation on a table which has a
> listen
Bruce Momjian writes:
> Peter Eisentraut wrote:
>> discernible benefits. But you can't expect a lot of people or employers
>> to reserve time on top of that for handholding other people's patches
>> and for other "community" stuff that has no easy to measure benefits.
>
> Totally agree. It is t
Hi,
Josh Berkus writes:
>>> Let's NOT start that discussion again.
Don't worry, no aim here to.
> Overall, I'm seeing this patch proposal suffer from an extreme excess of
> bike-shedding.
Not only that. See above.
> My proposal is this:
>
> (1) that we support the idea of a patch which allows
On Thu, Nov 12, 2009 at 4:25 AM, Tom Lane wrote:
>> One possible solution would be to write to the queue before committing
>> and adding the TransactionID. Then other backends can check if our
>> TransactionID has successfully committed or not. Not sure if this is
>> worth the overhead however...
On Thu, Nov 12, 2009 at 5:04 AM, Simon Riggs wrote:
> On Sun, 2009-11-08 at 20:52 -0500, Robert Haas wrote:
>
>> I would personally prefer not to be involved in the management of the
>> next CommitFest. Having done all of the July CommitFest and a good
>> chunk of the September CommitFest, I am f
Hi,
On Thursday 12 November 2009 12:46:46 Robert Haas wrote:
> Perhaps for next release we should consider spacing the CommitFests
> out a little more.
That may lead to quite a bit frustration on the contributor side though. It
can be very frustrating to have no input for a even longer timeframe
On Thu, Nov 12, 2009 at 6:49 AM, Andres Freund wrote:
> On Thursday 12 November 2009 12:46:46 Robert Haas wrote:
>> Perhaps for next release we should consider spacing the CommitFests
>> out a little more.
> That may lead to quite a bit frustration on the contributor side though. It
> can be very
On Thu, Nov 12, 2009 at 6:27 PM, Simon Riggs wrote:
> I agree with you, though it has taken some time to understand what you
> said and at first my reaction was to disagree. I think the responses you
> got on this are because you dived straight in with a question before
> explaining other things a
On Thu, 2009-11-12 at 21:45 +0900, Fujii Masao wrote:
> But, as I said on my first post on this thread, even such low-frequent
> fsync-WAL-before-buffer-flush might cause a response time spike on the
> primary because the walreceiver must sleep during that fsync. I think
> that leaving the WAL-log
Itagaki Takahiro wrote:
> Here is a patch to support "rewrite" version of VACUUM FULL.
> It was called "VACUUM REWRITE" in the past disucussin,
> but I choose the following syntax for now:
>
> VACUUM ( FULL [ INPLACE | REPLACE ] ) [ table_name ]
>
> The reason is to contrast the new REPLACE
Itagaki Takahiro wrote:
> We still need traditional VACUUM FULL behavior for system catalog because
> we cannot change relfilenode for them. Also, VACUUM FULL REPLACE is not
> always better than traditional VACUUM FULL; the new version requires
> additional disk space and might be slower if we hav
BTW I think the vacstmt.options change, which seems a reasonable idea to
me, could be extracted from the patch and applied separately. That'd
reduce the size of the patch somewhat.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting,
2. The payload parameter is optional. A notifying client can either call
"NOTIFY foo;" or "NOTIFY foo 'payload';". The length of the payload is
currently limited to 128 characters... Not sure if we should allow longer
payload strings...
Might be a good idea to make the max the same as the max l
On ons, 2009-11-11 at 19:45 -0500, Tom Lane wrote:
> > try
> > insert
> > catch unique_constraint_violation
> > update
> > end try
>
> > this will end up cluttering the logs with all the constraint violation
> > messages.
>
> Really? It's not supposed to.
There might be a different bug
On Thu, Nov 12, 2009 at 8:25 AM, Andrew Chernow wrote:
>
2. The payload parameter is optional. A notifying client can either call
"NOTIFY foo;" or "NOTIFY foo 'payload';". The length of the payload is
currently limited to 128 characters... Not sure if we should allow
longer
>>>
Peter Eisentraut writes:
> There might be a different bug here. This doesn't look right:
The UPDATE lacks a WHERE clause :-(
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgre
Fujii Masao writes:
> The problem is that fsync needs to be issued too frequently, which would
> be harmless in asynchronous replication, but not in synchronous one.
> A transaction would have to wait for the primary's and standby's fsync
> before returning a "success" to a client.
Surely that is
Andrew Gierth writes:
> A followup question: currently the code uses the "datum" interface for
> tuplesort. Obviously with multiple columns the slot interface is used
> instead; but is there any performance advantage for staying with the
> datum interface for the single-column case?
No idea ... m
What advantage is there in limiting it to a tiny size? This is a
'payload' after all...an arbitrary data block. Looking at the patch I
noticed the payload structure (AsyncQueueEntry) is fixed length and
designed to lay into QUEUE_PAGESIZE (set to) BLCKSZ sized pages.
H. Looks like the
On Fri, Nov 06, 2009 at 09:53:20PM -0500, Andrew Dunstan wrote:
> Joshua Tolley wrote:
>> I looked through the
>> regression tests and didn't find any that used plperl -- should we add one
>> for
>> this (or for this and all kinds of other stuff)? Is there some way to make
>> running the regressi
On ons, 2009-11-04 at 16:02 +0200, Peter Eisentraut wrote:
> Here is a patch to support arrays in PL/Python as parameters and
> return values.
Slightly updated version with fixed reference counting.
diff --git a/src/pl/plpython/expected/plpython_types.out b/src/pl/plpython/expected/plpython_types.
On Thu, Nov 12, 2009 at 3:09 PM, Andrew Chernow wrote:
>>
>> What advantage is there in limiting it to a tiny size? This is a
>> 'payload' after all...an arbitrary data block. Looking at the patch I
>> noticed the payload structure (AsyncQueueEntry) is fixed length and
>> designed to lay into QUE
Folks,
Here's expected behavior:
davidfet...@postgres=# SELECT array(values(1),(null));
?column?
──
{1,NULL}
(1 row)
The next one is just plain unexpected. Either it's a bug, or it needs
more documentation in the function description in the docs, \df+
output, etc.
davidfet...@postgr
On Thu, Nov 12, 2009 at 3:30 PM, Merlin Moncure wrote:
> Couple of questions:
>
> *) is BLCKSZ a hard requirement, that is, coming from the slru
> implementation, or can QUEUE_PAGESIZE be bumped independently of block
> size.
It's the size of slru's pages.
> *) why not make the AsyncQueueEntry d
So I think we're agreed on adding a variable_conflict GUC for plpgsql.
The straight-and-narrow way to do it would be to make this a custom
GUC that's defined only when plpgsql is dynamically loaded into the
backend. However that implies a lot of notational overhead, notably
having to put plpgsql i
--On 12. November 2009 15:48:44 + Greg Stark wrote:
I'm beginning to think the right solution is to reject the idea of
adding a payload to the NOTIFY mechanism and instead provide a queue
contrib module which provides the interface people want.
Isn't PgQ already the solution you have in
David Fetter writes:
> The next one is just plain unexpected.
array_to_string ignores null elements. What do you think it should do
with them?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Thu, Nov 12, 2009 at 11:13 AM, Tom Lane wrote:
> One reason to argue for the other way is that maybe it wouldn't only
> be consulted by plpgsql. In particular I can easily imagine SQL
> functions having the same issue as soon as someone gets around to
> letting them use names for their paramet
On Thu, Nov 12, 2009 at 11:30 AM, Tom Lane wrote:
> Joachim Wieland writes:
>> However I share Greg's concerns that people are trying to use NOTIFY
>> as a message queue which it is not designed to be.
>
> Yes. Particularly those complaining that they want to have very large
> payload strings --
On Thu, Nov 12, 2009 at 11:30 AM, Tom Lane wrote:
> Joachim Wieland writes:
>> However I share Greg's concerns that people are trying to use NOTIFY
>> as a message queue which it is not designed to be.
>
> Yes. Particularly those complaining that they want to have very large
> payload strings --
On Thu, Nov 12, 2009 at 11:39 AM, Robert Haas wrote:
> On Thu, Nov 12, 2009 at 11:30 AM, Tom Lane wrote:
>> Joachim Wieland writes:
>>> However I share Greg's concerns that people are trying to use NOTIFY
>>> as a message queue which it is not designed to be.
>>
>> Yes. Particularly those compl
Robert Haas writes:
> On Thu, Nov 12, 2009 at 11:13 AM, Tom Lane wrote:
>> One reason to argue for the other way is that maybe it wouldn't only
>> be consulted by plpgsql. In particular I can easily imagine SQL
>> functions having the same issue as soon as someone gets around to
>> letting them
On Thu, 2009-11-12 at 06:46 -0500, Robert Haas wrote:
> Having said that,
> I'm not capable of single-handedly effecting an on-time release
You're bloody good and the task needs to fit our capability anyway.
So, yes, you are.
> We need larger, more robust pools of
> committers, reviewers, comm
On Thu, Nov 12, 2009 at 11:31 AM, Simon Riggs wrote:
> Not a new idea, but I think we should require all patch submitters to do
> one review per submission. There needs to be a balance between time
> spent on review and time spent on dev. The only real way this happens in
> any community is by pee
Now you might say that yeah, that's the point, we're trying to enable
using NOTIFY in a different style. The problem is that if you are
trying to use NOTIFY as a queue, you will soon realize that it has
the wrong semantics for that --- in particular, losing notifies across
a system crash or cli
On Thu, Nov 12, 2009 at 4:30 PM, Tom Lane wrote:
> So while a payload string for NOTIFY has been on the to-do list since
> forever, I have to think that Greg's got a good point questioning
> whether it is actually a good idea.
Here's an example of why I'd like a payload (and not a queue in an
ad
Joachim Wieland writes:
> However I share Greg's concerns that people are trying to use NOTIFY
> as a message queue which it is not designed to be.
Yes. Particularly those complaining that they want to have very large
payload strings --- that's pretty much a dead giveaway that it's not
being use
On Wed, Nov 11, 2009 at 2:03 PM, Josh Berkus wrote:
>> I'd be happy to get together at some pre-appointed hour this weekend
>> (Saturday / Sunday) to talk it over by phone / IRC. PDXPUG was already
>> planning to get together to review some patches this Sunday from 3-5pm
>> PST, so that is a conv
However I share Greg's concerns that people are trying to use NOTIFY
as a message queue which it is not designed to be.
When you have an established libpq connection waiting for notifies it is
not unreasonable to expect/desire a payload. ISTM, the problem is that
the initial design was half
On Thu, Nov 12, 2009 at 8:31 AM, Simon Riggs wrote:
> Not a new idea, but I think we should require all patch submitters to do
> one review per submission. There needs to be a balance between time
> spent on review and time spent on dev. The only real way this happens in
> any community is by pee
Tom Lane wrote:
Fujii Masao writes:
The problem is that fsync needs to be issued too frequently, which would
be harmless in asynchronous replication, but not in synchronous one.
A transaction would have to wait for the primary's and standby's fsync
before returning a "success" to a client.
In a few days the 3rd 8.5 development CommitFest, 2009-11, is going to
kick off, with the end goal being an alpha3 prerelease. If you have a
patch in progress, you'll need to submit it before the deadline of
2009-11-15 00:00:00 GMT for it to be considered during this round:
http://wiki.postgr
Simon Riggs escreveu:
> So, I
> propose that we simply ignore patches from developers until they have
> done sufficient review to be allowed to develop again.
>
Is it really impolite for a first-contributor, no?
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pgsql-hacker
On Thu, Nov 12, 2009 at 11:20:26AM -0500, Tom Lane wrote:
> David Fetter writes:
> > The next one is just plain unexpected.
>
> array_to_string ignores null elements. What do you think it should
> do with them?
It should concatenate them, i.e. return a NULL if the array includes
any NULLs. Tha
On 11/12/09 9:45 AM, Greg Smith wrote:
> For lack of a more qualified volunteer, I'll be handling the initial
> round of patch assignments and reviewer organization.
Hmmm? Who's more qualified than you, exactly?
--Josh Berkus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
> That's basically just it: Assume bashing is part of the process. Don't
> think of it as bashing. Take the constructive criticism from it, ignore
> the rest. Assume only one out of three feature ideas will make it.
> Apply the prerequisite amount of gamesmanship to the system and tune
> your
Tom Lane wrote:
David Fetter writes:
The next one is just plain unexpected.
array_to_string ignores null elements. What do you think it should do
with them?
regards, tom lane
This seems somewhat related to the long-running discussion from back in
Februar
> I like this idea. Perhaps also if a person is reviewing a patch for
> the first time, we could make some effort to get a more experienced
> person paired up with them.
When I was CFM last year, I assigned patches for review first if the
patch author was doing a review themselves. Patches whose
On Thu, Nov 12, 2009 at 1:25 PM, Albert Cervera i Areny
wrote:
> A Dijous, 12 de novembre de 2009, Euler Taveira de Oliveira va escriure:
>> Simon Riggs escreveu:
>> > So, I
>> > propose that we simply ignore patches from developers until they have
>> > done sufficient review to be allowed to deve
A Dijous, 12 de novembre de 2009, Euler Taveira de Oliveira va escriure:
> Simon Riggs escreveu:
> > So, I
> > propose that we simply ignore patches from developers until they have
> > done sufficient review to be allowed to develop again.
>
> Is it really impolite for a first-contributor, no?
>
On Thu, Nov 12, 2009 at 1:28 PM, Steve Crawford
wrote:
> Although it might cause a fair amount of backward-compatibility trouble, the
> string representation could either use NULL to represent a null element as
> is allowed in other contexts or require that empty-string elements be
> represented a
2009/11/13 Euler Taveira de Oliveira :
> Simon Riggs escreveu:
>> So, I
>> propose that we simply ignore patches from developers until they have
>> done sufficient review to be allowed to develop again.
>>
> Is it really impolite for a first-contributor, no?
>
I support Simon's proposal, but I thi
On Thu, Nov 12, 2009 at 11:40 AM, Merlin Moncure wrote:
> I'm sorry, the 128 character limit is simply lame (other than for
> unsolvable implementation/performance complexity which I doubt is the
> case here), and if that constraint is put in by the implementation,
> than the implementation is bus
On Thu, 2009-11-12 at 15:52 -0200, Euler Taveira de Oliveira wrote:
> Simon Riggs escreveu:
> > So, I
> > propose that we simply ignore patches from developers until they have
> > done sufficient review to be allowed to develop again.
>
> Is it really impolite for a first-contributor, no?
I beli
Robert Haas escribió:
> On Thu, Nov 12, 2009 at 1:25 PM, Albert Cervera i Areny
> wrote:
> > A Dijous, 12 de novembre de 2009, Euler Taveira de Oliveira va escriure:
> >> Simon Riggs escreveu:
> >> > So, I
> >> > propose that we simply ignore patches from developers until they have
> >> > done suf
I wrote:
> Fair enough. I'll start writing the custom GUC then.
While testing that, I noticed a pre-existing GUC limitation that maybe
we should do something about now: it does not work very nicely for
custom SUSET GUC variables. Normally, if a variable is SUSET, an
ordinary user can't do ALTER
On Thu, Nov 12, 2009 at 01:33:41PM -0500, Robert Haas wrote:
> On Thu, Nov 12, 2009 at 1:28 PM, Steve Crawford
> wrote:
> > Although it might cause a fair amount of backward-compatibility
> > trouble, the string representation could either use NULL to
> > represent a null element as is allowed in
Robert Haas writes:
> On Thu, Nov 12, 2009 at 1:28 PM, Steve Crawford
> wrote:
>> Although it might cause a fair amount of backward-compatibility trouble, the
>> string representation could either use NULL to represent a null element as
>> is allowed in other contexts or require that empty-string
On Thu, 2009-11-12 at 11:36 -0500, Robert Haas wrote:
> I agree. I would quibble only with the details. I think we should
> require patch authors to act as a reviewer for any CommitFest for
> which they have submitted patches. We don't need every patch author
> to review as many patches as they
On Thu, Nov 12, 2009 at 1:27 PM, Josh Berkus wrote:
>
>> That's basically just it: Assume bashing is part of the process. Don't
>> think of it as bashing. Take the constructive criticism from it, ignore
>> the rest. Assume only one out of three feature ideas will make it.
>> Apply the prerequi
--On 4. November 2009 09:57:27 -0500 Tom Lane wrote:
I think the
consensus was that the way to fix this (along with some other problems)
is to start representing NOT NULL constraints in pg_constraint, turning
attnotnull into just a bit of denormalization for performance.
I've just started
Josh Berkus wrote:
On 11/12/09 9:45 AM, Greg Smith wrote:
For lack of a more qualified volunteer, I'll be handling the initial
round of patch assignments and reviewer organization.
Hmmm? Who's more qualified than you, exactly?
I was alluding to the fact that Robert isn't available
I'm not addressing the complaints Emmanuel has about patch submission,
but was inspired by what he said. I hesitated to post this to
-hackers, but my hope is that my comments are taken in the spirit of
reflection.
I've been thinking about the Postgres community and things that
differentiate it fro
Hi
While trying to create a domain over an array type to enforce a certain
shape or certain contents of an array (like the array being only
one-dimensional or not containing NULLs), I've stumbled over what I
believe to be a bug in postgresql 8.4
It seems that check constraints on domains are *no
Greg Smith writes:
> The set of patches I have the least feel for are the five ECPG
> submissions, some of which were reviewed already. I would particularly
> appreciate any early information reviewers might provide about their
> capability/willingness to work on that set. Those are not so ea
Hello Everyone,
I recently spent some time comparing the various techniques used to
backup/export MySQL, SQLite, and PostgreSQL databases. So far, pg_dump
is the best tool I've used. I was well pleased with its efficient
syntax and functionality. However, I have two feature requests that I
On Thu, Nov 12, 2009 at 1:45 PM, Jeff Davis wrote:
> On Thu, 2009-11-12 at 11:36 -0500, Robert Haas wrote:
>> I agree. I would quibble only with the details. I think we should
>> require patch authors to act as a reviewer for any CommitFest for
>> which they have submitted patches. We don't nee
On Nov 12, 2009, at 10:46 AM, David Fetter wrote:
> My question boils down to, "why is this string concatenation different
> from all other string concatenations?"
Does it have something to do with afikoman?
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
Boszormenyi Zoltan escribió:
> Alvaro Herrera írta:
> > I have applied this patch after some tinkering. I mainly added support
> > for "fetch_args: FORWARD opt_from_in name" and "BACKWARD opt_from_in
> > name" in ecpg.addons which apparently you forgot.
>
> Thanks. Your fix is correct if this pa
Tom Lane wrote:
> Greg Smith writes:
> > The set of patches I have the least feel for are the five ECPG
> > submissions, some of which were reviewed already. I would particularly
> > appreciate any early information reviewers might provide about their
> > capability/willingness to work on that
On Thu, Nov 12, 2009 at 11:46:54AM -0800, David Wheeler wrote:
> On Nov 12, 2009, at 10:46 AM, David Fetter wrote:
>
> > My question boils down to, "why is this string concatenation
> > different from all other string concatenations?"
>
> Does it have something to do with afikoman?
I was wonderi
Here's the patch to support Python >=3.1 with PL/Python. The
compatibility code is mostly in line with the usual 2->3 C porting
practice and is documented inline.
I needed to create an arguably weird hack to manage the regression
tests. Instead of creating a new expected file for pretty much eve
Robert Haas escribió:
> I used to feel this way, too. I'm not sure whether it's really worse
> at first, or whether it just seems worse a first until you get used to
> it. There is no getting around the fact that this is a community of
> very smart people. I work at a company where I'm the only
On Tue, 03 Nov 2009 10:32:17 -0800 Josh Berkus wrote:
> The same goes for other OSS projects. There's quite a few random OSS
> apps which were created on PG 7.4 and have never offered their users an
> upgrade path (Gnuworld comes to mind). They need an EOL announcement to
> get them motivated to
On Thu, Nov 12, 2009 at 2:49 PM, Alvaro Herrera
wrote:
> Boszormenyi Zoltan escribió:
>> Alvaro Herrera írta:
>
>> > I have applied this patch after some tinkering. I mainly added support
>> > for "fetch_args: FORWARD opt_from_in name" and "BACKWARD opt_from_in
>> > name" in ecpg.addons which app
On Thu, 2009-11-12 at 14:43 -0500, Robert Haas wrote:
> > Not all contributors are fluent English readers and writers.
> >
> > I certainly do not discourage those people from reviewing, but I can
> > understand how it might be more frustrating and less productive for
> > them. An important part of
Andreas 'ads' Scherbaum wrote:
On Tue, 03 Nov 2009 10:32:17 -0800 Josh Berkus wrote:
The same goes for other OSS projects. There's quite a few random OSS
apps which were created on PG 7.4 and have never offered their users an
upgrade path (Gnuworld comes to mind). They need an EOL announ
--On 12. November 2009 15:23:06 -0500 Andrew Dunstan
wrote:
What I and others have been arguing is necessary to do EOL right is a
serious amount of notice, by way of press releases etc. We can't expect
users to keep polling our web site to see if there's an EOL. That means
we need to prepar
> I think that's the key argument here. We have several customers, which
> need a very careful and time consuming evaluation before they can go
> into production with a new platform, which is quite time consuming and
> needs significant preparation for them. Announcing an EOL early in time
> would
consistently fails when compiled on ubuntu 9.10 here (on mini 10v).
regression.diffs.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Bernd Helmle writes:
> My first idea is to just introduce a special contype in pg_constraint
> representing a NOT NULL constraint on a column, which holds all required
> information to do the mentioned maintenance stuff on them and to keep most
> of the current infrastructure. Utility commands
Peter Eisentraut writes:
> Here's the patch to support Python >=3.1 with PL/Python. The
> compatibility code is mostly in line with the usual 2->3 C porting
> practice and is documented inline.
There was considerable debate earlier about whether we wanted to treat
Python 3 as a separate PL so it
On Thu, Nov 12, 2009 at 3:12 PM, Jeff Davis wrote:
> On Thu, 2009-11-12 at 14:43 -0500, Robert Haas wrote:
>> > Not all contributors are fluent English readers and writers.
>> >
>> > I certainly do not discourage those people from reviewing, but I can
>> > understand how it might be more frustrati
Grzegorz Jaskiewicz wrote:
consistently fails when compiled on ubuntu 9.10 here (on mini 10v).
+ ERROR: incompatible library
"/home/kgrittn/postgresql-8.4.0/src/test/regress/refint.so": version
mismatch
+ DETAIL: Server is version 8.4, library is version 8.3.
You might take this as
Grzegorz Jaskiewicz writes:
> consistently fails when compiled on ubuntu 9.10 here (on mini 10v).
Locale issue maybe? Looks like it has some odd ideas about text
sort order.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
Tom Lane wrote:
AFAIK the ecpg patches are all waiting on Michael Meskes to have time
to review/commit them. ecpg is pretty much his turf and no other
committers are likely to touch these patches.
Great to know, and since some of the regular reviewers already made a
pass through them there's pr
Mark Hammonds writes:
> 1. View Based Exports
> In addition to being able to dump specific tables, it seems useful to
> be able to quickly specify and dump entire views.
Isn't this pretty much the same thing as your #2? A view in PG isn't
materialized, it's nothing but a custom SELECT.
> 2.
On Thu, 12 Nov 2009 15:23:06 -0500 Andrew Dunstan wrote:
> Andreas 'ads' Scherbaum wrote:
> > On Tue, 03 Nov 2009 10:32:17 -0800 Josh Berkus wrote:
> >
> >
> >> The same goes for other OSS projects. There's quite a few random OSS
> >> apps which were created on PG 7.4 and have never offered th
Tom Lane escribió:
> I wrote:
> > Fair enough. I'll start writing the custom GUC then.
>
> While testing that, I noticed [...]
With all this fallout, I think it would be cleaner to step back and make
it a regular GUC variable, not custom. Pretending that plpgsql is
somehow not an integral part
On Thu, 2009-11-12 at 23:09 +0100, Andreas 'ads' Scherbaum wrote:
> On Thu, 12 Nov 2009 15:23:06 -0500 Andrew Dunstan wrote:
>
> > Andreas 'ads' Scherbaum wrote:
> > > On Tue, 03 Nov 2009 10:32:17 -0800 Josh Berkus wrote:
> > >
> > >
> > >> The same goes for other OSS projects. There's quite a
Alvaro Herrera writes:
> With all this fallout, I think it would be cleaner to step back and make
> it a regular GUC variable, not custom. Pretending that plpgsql is
> somehow not an integral part of the system is not completely true
> anyway. Yes, we're playing favorites in the PL camp here, bu
On Thu, Nov 12, 2009 at 13:55, Tom Lane wrote:
> I'd go for the first of those, for sure. Testing attnotnull is
> significantly cheaper than enforcing a generic constraint expression,
> and NOT NULL is a sufficiently common case to be worth worrying about
> optimizing it.
When I looked at doing
On the subject topic, I have to say that I don't see where Robert
hasn't met the qualifications mentioned so far on this thread as
required to promote someone to the committer level; are there some
requirements which exist but haven't been mentioned?
Regarding the specific issues below, which see
Alex Hunsaker writes:
> On Thu, Nov 12, 2009 at 13:55, Tom Lane wrote:
>> I'd go for the first of those, for sure. Â Testing attnotnull is
>> significantly cheaper than enforcing a generic constraint expression,
>> and NOT NULL is a sufficiently common case to be worth worrying about
>> optimizin
1 - 100 of 152 matches
Mail list logo
