Re: [HACKERS] EOL for 7.4?
On Fri, Nov 13, 2009 at 02:47:56AM +, Greg Stark wrote: > On Fri, Nov 13, 2009 at 2:35 AM, daveg wrote: > > I suggest we announce now that both 7.4 and 8.0 will EOL when 8.5 is > > expected > > to ship, or to comfort those who never use .0 versions when 8.5.1 ships. > > What would this mean? How would it be different than the status quo? I suppose it would mean posting periodic prominent notices, moving the sources to the OLD directory, that sort of thing. I thought that was the topic of this thread? -dg -- David Gould da...@sonic.net 510 536 1443510 282 0869 If simplicity worked, the world would be overrun with insects. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] CommitFest 2009-11 Call for Reviewers
On Thu, Nov 12, 2009 at 04:52:20PM -0300, Alvaro Herrera wrote: > FWIW I committed the parts of one of these patches that touched the core Thanks for your help. > grammar mostly, because I think those might have been holding Michael > back a bit. Hopefully that'll make it easier for him to review the No, not really. I don't mind reviewing and committing to the core grammar at all. What holds me back is simply my lack of time. michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: mes...@jabber.org VfL Borussia! Forca Barca! Go SF 49ers! Use: Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] CommitFest 2009-09, two weeks on
On Thu, Nov 12, 2009 at 03:07:27PM -0500, Robert Haas wrote: > > If you want to submit patches in a series like this one, they need to be > > considered standalone, I think. The Linux kernel devs work differently > > than us here. > > Zoltan broke them up because Michael asked him to do so. Actually these patchsets add different features. I see no reason why they should be done as one patch. However, I haven't had the time to look into the latest ones, but at least that was the situation when I asked Zoltan to split the patch. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: mes...@jabber.org VfL Borussia! Forca Barca! Go SF 49ers! Use: Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch committers
Greg Smith writes: > Since most people have an upper limit on how much community time they > can spend, every minute spent reviewing is one you're not working on > your own patches during. The way you're describing the qualification > process, it would be easy to conclude that there's a reviewer ladder, > and a developer ladder, and only climbing the latter leads to being a > committer--that no matter how much review you do, it doesn't really > count as a committer grade skill. Well, we only instituted the commitfest system last year; before that there wasn't any formal concept of people reviewing patches at all. Nobody has yet been promoted to committer on the basis of their reviewing work, but I don't wish to suggest that it couldn't happen. > I'm not sure that's the message you want to be sending, because anyone > who dreams of being a committer is going to stay as far away from doing > review as they can if that notion spreads. Based on the growing > frustration with "doing review doesn't leave me with time for my own > patches" I keep hearing, that perception is already something to be wary > of. I'll let you in on a secret: it feels about like that in the committer trenches too. At this point it seems that one of the major practical reasons for appointing new committers would be their willingness to help with review/commit of incoming patches. If anyone is thinking there's a ladder they can climb that doesn't have that responsibility at the top, I'm afraid they're mistaken. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] CTE containing ambiguous columns
Robert Haas writes: > Suppose you do this: > create table animals (id serial primary key, name varchar not null); > Then you can do this: > with beings as (select * from animals) select * from beings where id = 1; > But not this: > with beings as (select * from animals a1, animals a2) select * from > beings where id = 1; No different from regression=# select * from (animals a1 cross join animals a2) x where id = 1; ERROR: column reference "id" is ambiguous LINE 1: ...ct * from (animals a1 cross join animals a2) x where id = 1; ^ There's no way to access the a1/a2 aliases here, either; and that rule goes back to SQL92 or maybe further. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] SE-PgSQL/lite (r2429)
KaiGai Kohei wrote: > I found a uncertain term in your comment. > It seems to me the "model" has two meanings in this context. > - The way to make access control decision (allowed? or denied?). > - The granularity of access controls (tables? columns? or tuples?). > What I meant by "the SEPosgreSQL model for row filtering" was the original implementation you had, where row filtering was handled by code specific to SEPostgreSQL, not something generic enough to be used for other purposes. I wasn't sure what if anything from there was still in the patch, and you answered that clearly enough. Thanks for clarifying where things are at. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] write ahead logging in standby (streaming replication)
Fujii Masao wrote: On Fri, Nov 13, 2009 at 1:49 PM, Greg Smith wrote: Right, those are the possibilities, all four of them have valid use cases in the field and are worth implementing. I don't like the label "semi-synchronous replication" myself, but it's a valuable feature to implement, and that is unfortunately the term other parts of the industry use for that approach. BTW, MySQL and DRBD use the term "semi-synchronous": http://forge.mysql.com/wiki/ReplicationFeatures/SemiSyncReplication http://www.drbd.org/users-guide/s-replication-protocols.html Yeah, that's the "other parts of the industry" I was referring to. MySQL uses "semi-synchronous" to distinguish between its completely asynchronous default replication mode and one where it provides a somewhat safer implementation. The description reads more as "asynchronous with some synchronous elements", not "one style of synchronous implementation". None of their documentation wanders into the problem area here by calling it a true synchronous solution when it's really not--MySQL Cluster is their synchronous vehicle. It's fine to adopt the term "semi-synchronous", as it's become quite popular and people are going to label the PG implementation with it regardless of what is settled on here. But we should all try to be careful to use it as correctly as possible. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] write ahead logging in standby (streaming replication)
Hi Greg and Fujii, Just a point on terminology: there's a difference in the usage of semi-synchronous between DRBD and MySQL semi-synchronous replication, which was originally developed by Google. In the Google case semi-synchronous replication is a quorum algorithm where clients receive a commit notification only after at least one of N slaves has received the replication event. In the DRBD case semi-synchronous means that events have reached the slave but are not necessarily durable. There's no quorum. Of these two usages the Google semi-sync approach is the more interesting because it avoids the availability problems associated with fully synchronous operation but gets most of the durability benefits. Cheers, Robert On 11/12/09 9:29 PM PST, "Fujii Masao" wrote: > On Fri, Nov 13, 2009 at 1:49 PM, Greg Smith wrote: >> Right, those are the possibilities, all four of them have valid use cases in >> the field and are worth implementing. I don't like the label >> "semi-synchronous replication" myself, but it's a valuable feature to >> implement, and that is unfortunately the term other parts of the industry >> use for that approach. > > BTW, MySQL and DRBD use the term "semi-synchronous": > http://forge.mysql.com/wiki/ReplicationFeatures/SemiSyncReplication > http://www.drbd.org/users-guide/s-replication-protocols.html > > Regards, > > -- > Fujii Masao > NIPPON TELEGRAPH AND TELEPHONE CORPORATION > NTT Open Source Software Center > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] next CommitFest
Robert Haas wrote: > > That wasn't my intention. I really was assuming that we would just > let those patches drop on the floor, and that they would not be picked > up either by reviewers or committers. Surely it should depend on the nature of the patch. For an extreme strawman, segfault fixes almost certainly shouldn't be dropped. Same for docs patches that clarify the product. I think the majority of my contributions to open source this decade have been of that nature (a few links to examples in postgres and postgis follow). Maybe a better policy would be: "if you reviewed patches, a reviewer will be assigned -- if you didn't, your patch is at the mercy of reviewers volunteering to review it based on their own interest in your patch" that way patches that the community really wants could get in anyway. http://postgis.refractions.net/pipermail/postgis-users/2005-April/007762.html http://archives.postgresql.org/pgsql-performance/2009-03/msg00252.php http://postgis.refractions.net/pipermail/postgis-users/2005-April/007704.html http://postgis.refractions.net/pipermail/postgis-devel/2005-April/001341.html -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] SE-PgSQL/lite (r2429)
Greg Smith wrote: > KaiGai Kohei wrote: >> In the v8.4 development cycle, I got a suggestion to reduce >> a burden of reviewer to split off a few functionalities, such >> as "security_context" system column and row-level access controls. >> > I lost track of this patch and related bits somewhere along the way, had > to triage my unread mail a few times. Could someone summarize how it now > fits into plans for more general row-level access controls in the > database? I know incompatibilities between the SEPosgreSQL model for row > filtering and thoughts for a more general permissions feature that did > something similar were a major design issue in the early 8.4 versions of > SEPostgreSQL, and that as you say you've been working on that. I'm not > sure what relationship there is between those two today though, or > exactly where the general non-SELinux row filtering is at on the roadmap. At least, I don't have a plan to submit a patch for row-level access controls in the v8.5 development cycle. We should focus on the "lite" version here. On that basis, I shall propose the row-level access controls after the current efforts getting closed. I found a uncertain term in your comment. It seems to me the "model" has two meanings in this context. - The way to make access control decision (allowed? or denied?). - The granularity of access controls (tables? columns? or tuples?). I think you are saying about the latet point. In my plan, I'll propose a feature something like Oracle Virtual Private Database which filters violated rows based on the decision making function. (e.g tbl.username = getpgusername() ) Needless to say, it is a general non-SELinux feature. But, if we have such a PG-VPD, it is not difficult to implement a decision making function based on SELinux. Is it correct for the answer? Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] write ahead logging in standby (streaming replication)
On Fri, Nov 13, 2009 at 1:49 PM, Greg Smith wrote: > Right, those are the possibilities, all four of them have valid use cases in > the field and are worth implementing. I don't like the label > "semi-synchronous replication" myself, but it's a valuable feature to > implement, and that is unfortunately the term other parts of the industry > use for that approach. BTW, MySQL and DRBD use the term "semi-synchronous": http://forge.mysql.com/wiki/ReplicationFeatures/SemiSyncReplication http://www.drbd.org/users-guide/s-replication-protocols.html Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] next CommitFest
On Thu, Nov 12, 2009 at 11:50 PM, Bruce Momjian wrote: > Robert Haas wrote: >> >> We just wouldn't assign round-robin reviewers to such patches. ?If >> >> someone wants to volunteer, more power to them, but we would encourage >> >> people to focus their efforts on the patches of people who were >> >> themselves reviewing. ?It's important to keep in mind that "valid" is >> >> not a boolean. ?Some patches are perfect the day they roll in, but not >> >> too many. ?It takes work to get them committable, and I don't see why >> >> anyone should have an expectation that they can have that help for >> >> themselves without doing the same thing for other people. >> > >> > OK, but the problem I see there is that the reviewers are there to >> > assist the committers; ?if no one reviews something, it just makes more >> > work for the committers. >> >> That wasn't my intention. I really was assuming that we would just >> let those patches drop on the floor, and that they would not be picked >> up either by reviewers or committers. I don't think this would cause >> as many problems in practice as perhaps you fear, because I think it >> will just motivate people to act as reviewers. Writing a patch is >> typically more time-consuming than reviewing one, at least IME, with >> some exceptions of course. I wouldn't spend 20 hours writing a patch >> and then let it fall out because I wasn't willing to spend 2 or 3 >> hours reviewing someone else's patch, and I don't think other regular >> contributors will either. > > OK, but that is certainly a different system than we have now. In your > system, committers would be told to ignore patches that were submitted > by repeated patch submitters who never review, or even we just never put > on the commit fest page. I think they would probably get added to the CommitFest page and then marked Rejected with a suitable explanation. > I am just trying to nail down exactly how that would work --- that's a > pretty Draconian system. I don't really agree, but obviously I respect your opinion, and clearly, this is not a policy that can be implemented without some degree of consensus. I fear, however, that if we don't motivate regular contributors to also review, then we will have a shortage of reviewers, especially highly-qualified reviewers. If there is no stigma attached to submitting patches and never volunteering to review, then even people who have reviewed in the past may eventually decide it isn't worth the effort. I am personally quite tired of reviewing patches for people who don't in turn review mine (or someone's). It makes me feel like not working on this project. If we can solve that problem without implementing a policy of this type, that is good. I would much prefer to run by the honor system rather than having to threaten to drop patches, but only if the honor system actually works. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] write ahead logging in standby (streaming replication)
On Fri, Nov 13, 2009 at 11:54 AM, Greg Stark wrote: > I think my definition would be that a query against the replica will > produce the same result as a query against the master -- and that that > will be the case even after a system failure. That might not > necessarily mean that the log entry is fsynced on the replica, only > that it's fsynced in a location where the replica will have access to > it when it runs recovery. Agreed. > I do have a different question though. What do you plan to do if > there's a failure when they're out of sync? The master hasn't > responded to the commit yet because it's still waiting on the replica > to respond but it has already recorded the commit itself. When it > comes back up it's out of sync with the replica and has to resend > those records? What if the replica has already received it and it was > the confirmation which was lost? If the connection is not closed, the resending is not required because TCP would guarantee that such records arrive at the standby someday. Otherwise, the standby re-connects to the primary, and asks for the missing records, so the resending would be done. Since only the missing records are requested, the already received records don't reach the standby again, I think. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] SE-PgSQL/lite (r2429)
KaiGai Kohei wrote: > In the v8.4 development cycle, I got a suggestion to reduce > a burden of reviewer to split off a few functionalities, such > as "security_context" system column and row-level access controls. > I lost track of this patch and related bits somewhere along the way, had to triage my unread mail a few times. Could someone summarize how it now fits into plans for more general row-level access controls in the database? I know incompatibilities between the SEPosgreSQL model for row filtering and thoughts for a more general permissions feature that did something similar were a major design issue in the early 8.4 versions of SEPostgreSQL, and that as you say you've been working on that. I'm not sure what relationship there is between those two today though, or exactly where the general non-SELinux row filtering is at on the roadmap. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] next CommitFest
Robert Haas wrote: > >> We just wouldn't assign round-robin reviewers to such patches. ?If > >> someone wants to volunteer, more power to them, but we would encourage > >> people to focus their efforts on the patches of people who were > >> themselves reviewing. ?It's important to keep in mind that "valid" is > >> not a boolean. ?Some patches are perfect the day they roll in, but not > >> too many. ?It takes work to get them committable, and I don't see why > >> anyone should have an expectation that they can have that help for > >> themselves without doing the same thing for other people. > > > > OK, but the problem I see there is that the reviewers are there to > > assist the committers; ?if no one reviews something, it just makes more > > work for the committers. > > That wasn't my intention. I really was assuming that we would just > let those patches drop on the floor, and that they would not be picked > up either by reviewers or committers. I don't think this would cause > as many problems in practice as perhaps you fear, because I think it > will just motivate people to act as reviewers. Writing a patch is > typically more time-consuming than reviewing one, at least IME, with > some exceptions of course. I wouldn't spend 20 hours writing a patch > and then let it fall out because I wasn't willing to spend 2 or 3 > hours reviewing someone else's patch, and I don't think other regular > contributors will either. OK, but that is certainly a different system than we have now. In your system, committers would be told to ignore patches that were submitted by repeated patch submitters who never review, or even we just never put on the commit fest page. I am just trying to nail down exactly how that would work --- that's a pretty Draconian system. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] write ahead logging in standby (streaming replication)
Fujii Masao wrote:
Umm... what is your definition of "synchronous"? I'm planning to provide
four synchronization modes as follows, for v8.5. Does this fit in your
thought?
The primary waits ... before returning "success" of a transaction;
* nothing - asynchronous replication
* recv ACK - semi-synchronous replication
* fsync ACK - semi-synchronous replication
* redo ACK - synchronous replication
Or, in synchronous replication, we must wait a fsync and a redo ACK?
Right, those are the possibilities, all four of them have valid use
cases in the field and are worth implementing. I don't like the label
"semi-synchronous replication" myself, but it's a valuable feature to
implement, and that is unfortunately the term other parts of the
industry use for that approach.
But everyone needs to be extremely careful with the terminology here:
if you say "synchronous replication", that *only* means what you're
labeling "redo ACK" ("WAL ACK" really). "Synchronous replication"
should not be used as a group term that includes the semi-synchronous
variations, which are in fact asynchronous despite their marketing
name. If someone means semi-synchronous, but they say synchronous
thinking it's a shared term also applicable to the semi-synchronous
variations here, that's just going to be confusing for everyone.
--
Greg Smith2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
g...@2ndquadrant.com www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] next CommitFest
On Thu, Nov 12, 2009 at 11:31 PM, Bruce Momjian wrote: > Robert Haas wrote: >> >> Personally, I would not propose to impose this rule of first-time >> >> contributors, or even second-time contributors. ?But by about patch #3 >> >> I think everyone should be pitching in. >> > >> > I hate to ask, but how would we enforce this? ?Do we no longer apply >> > patches for 3rd-time submitters who have not reviewed? ?That seems to be >> > hurting us more than them. ? Are we prepared to discard valid patches >> > for this reason? >> >> We just wouldn't assign round-robin reviewers to such patches. If >> someone wants to volunteer, more power to them, but we would encourage >> people to focus their efforts on the patches of people who were >> themselves reviewing. It's important to keep in mind that "valid" is >> not a boolean. Some patches are perfect the day they roll in, but not >> too many. It takes work to get them committable, and I don't see why >> anyone should have an expectation that they can have that help for >> themselves without doing the same thing for other people. > > OK, but the problem I see there is that the reviewers are there to > assist the committers; if no one reviews something, it just makes more > work for the committers. That wasn't my intention. I really was assuming that we would just let those patches drop on the floor, and that they would not be picked up either by reviewers or committers. I don't think this would cause as many problems in practice as perhaps you fear, because I think it will just motivate people to act as reviewers. Writing a patch is typically more time-consuming than reviewing one, at least IME, with some exceptions of course. I wouldn't spend 20 hours writing a patch and then let it fall out because I wasn't willing to spend 2 or 3 hours reviewing someone else's patch, and I don't think other regular contributors will either. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [PATCH] Largeobject Access Controls (r2432)
The attached patch is a revised version of large object privileges based on the feedbacks at the last commit fest. List of updates: * Rebased to the latest CVS HEAD * Add pg_largeobject_aclcheck_snapshot() interface. In the read-only access mode, large object feature uses query's snaphot, not only SnapshotNow. This behavior also should be applied on accesses to its metadata. When it makes its access control decision, it has to fetch database acls from the system catalog. In this time, we scan the pg_largeobject_metadata with a snapshot of large object descriptor. (Note that it is SnapshotNow in read-write mode.) It enables to resolve the matter when access rights are changed during large objects are opened. * Add pg_dump support. * Replace all the "largeobject" by "large object" from user visible messages and documentation. * Remove ac_largeobject_*() routines because we decided not to share same entry points between DAC and MAC. * Add a description of large object privileges in SGML. * Add a definition of pg_largeobject_metadata in SGML. * \lo_list command supports both of v8.5 and prior version. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei sepgsql-02-blob-8.5devel-r2432.patch.gz Description: application/gzip -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] next CommitFest
Robert Haas wrote: > >> Personally, I would not propose to impose this rule of first-time > >> contributors, or even second-time contributors. ?But by about patch #3 > >> I think everyone should be pitching in. > > > > I hate to ask, but how would we enforce this? ?Do we no longer apply > > patches for 3rd-time submitters who have not reviewed? ?That seems to be > > hurting us more than them. ? Are we prepared to discard valid patches > > for this reason? > > We just wouldn't assign round-robin reviewers to such patches. If > someone wants to volunteer, more power to them, but we would encourage > people to focus their efforts on the patches of people who were > themselves reviewing. It's important to keep in mind that "valid" is > not a boolean. Some patches are perfect the day they roll in, but not > too many. It takes work to get them committable, and I don't see why > anyone should have an expectation that they can have that help for > themselves without doing the same thing for other people. OK, but the problem I see there is that the reviewers are there to assist the committers; if no one reviews something, it just makes more work for the committers. > All that having been said, the real shortage ATM is of committers > rather than reviewers. We have plenty of them, but many of them > commit almost nothing. I don't want to minimize the contributions of > the non-Tom committers, but Tom is numerically far and away committing > more than anyone else, and not small patches, either. Beyond the > fact that it makes the CommitFest slow, long, and not too much fun for > Tom, it also means that Tom has less time available to do things that > Only Tom Can Do. I venture to say that there will be Great Excitement > about the enhancements to the EPQ machinery and PL/pgsql that Tom has > recently effected. Well, if Tom hadn't had to single-handedly handle > so many patches last CF, maybe he would have done something else cool, > too. Totally agree. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] CTE containing ambiguous columns
Suppose you do this: create table animals (id serial primary key, name varchar not null); Then you can do this: with beings as (select * from animals) select * from beings where id = 1; But not this: with beings as (select * from animals a1, animals a2) select * from beings where id = 1; Because: ERROR: column reference "id" is ambiguous at character 82 STATEMENT: with beings as (select * from animals a1, animals a2) select * from beings where id = 1; ERROR: column reference "id" is ambiguous LINE 1: ...m animals a1, animals a2) select * from beings where id = 1; ^ My email program will probably mangle this, so the error cursor here is point to "id = 1", at the end, and saying that's ambiguous. Which is sorta kinda true, but the usual remedy of qualifying it with a relation name (here, beings.id) fails. And you can't quantify it with a1.id or a2.id either, they're out of scope. In some sense, the real problem is with "select *", because that is what is expanding into a non-unique list of column names. But you don't actually trigger an error unless you try to reference one; the same query works fine without the where clause. I'm not sure if there's anything useful we can do about this, but it definitely threw me for a loop. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] TRIGGER with WHEN clause
Itagaki Takahiro wrote: > Here is a updated TRIGGER with WHEN cluase patch. > I adjusted it to work with recent parser cleanup (*OLD* and *NEW*). I would like to volunteer for reviewing the patch in RR-stage. It seems to me an interesting feature. -- OSS Platform Development Division, NEC KaiGai Kohei -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Listen / Notify rewrite
On Nov 12, 2009, at 5:57 PM, Robert Haas wrote: > On Thu, Nov 12, 2009 at 8:44 PM, Josh Berkus wrote: >> On 11/12/09 8:30 AM, 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. >> >> Sure, people will abuse it as a queue. But people abuse arrays when >> they should be using child tables, use composite types to make data >> non-atomic, and use dblink when they really should be using schema. >> Does the potential for misuse mean that we should drop the features? No. > > I agree. We frequently reject features on the basis that someone > might do something stupid with them. It's lame and counterproductive, > and we should stop. The world contains infinite amounts of lameness, > but that's the world's problem, not ours. There is zero evidence that > this feature is only useful for stupid purposes, and some evidence > (namely, the opinions of esteemed community members) that it is useful > for at least some non-stupid purposes. Speaking as a consumer of this feature, my (mild) concern is not that by adding functionality it will make it possible to do new things badly, it's that it might make it harder (or impossible) to do currently supported things as well. I like the current notify. It's a good match for handling table based queues or for app-level-cache invalidation. Any changes that make it less good at that would be a step backwards. The more complex and flexible and "heavier" the changes, the more that concerns me. (Though a small payload - I'd settle for at least an integer - would be convenient, to allow invalidation of 20 different caches without needing 20 different LISTENs). Cheers, Steve -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] actualised funcs typmod patch
Hello I am sorry. I'll send a actualised version today. Pavel 2009/11/13 Alvaro Herrera : > Pavel Stehule escribió: >> Hello >> >> actualised version: enhance check inside sql function > > What is this against? It has a few suspicious chunks, such as > > *** > *** 358,364 > > funcexpr->funcid = funcid; > funcexpr->funcresulttype = rettype; > ! funcexpr->funcresulttypmod = -1; // TODO STEHULE > funcexpr->funcretset = retset; > funcexpr->funcformat = COERCE_EXPLICIT_CALL; > funcexpr->args = fargs; > --- 365,371 > > funcexpr->funcid = funcid; > funcexpr->funcresulttype = rettype; > ! funcexpr->funcresulttypmod = rettypmod; > funcexpr->funcretset = retset; > funcexpr->funcformat = COERCE_EXPLICIT_CALL; > funcexpr->args = fargs; > > > > This ended up in ./src/backend/parser/parse_func.c.rej > > There are other rejects and I'm not sure if I should fix them (at least > the first couple look trivial, though it's against a bunch of code > that last changed in Aug. last year) or ask for a better version ... > > -- > Alvaro Herrera http://www.CommandPrompt.com/ > PostgreSQL Replication, Consulting, Custom Development, 24x7 support > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Aggregate ORDER BY patch
Herewith a patch to implement agg(foo ORDER BY bar) with or without DISTINCT, etc. No artificial restrictions are imposed on what syntactical combinations are allowed. However, ORDER BY is not allowed with aggregates used as window functions (as per the existing restriction on DISTINCT). Included are regression tests but not docs yet, those will follow shortly in a separate patch (to save having to keep redoing the code patch like last time). Caveat: as discussed earlier, this patch changes the behaviour of array_agg(DISTINCT x) when applied to NULL inputs. Formerly, the NULLs were unconditionally skipped; now, they are treated just like DISTINCT or GROUP BY normally do. The previous restriction of agg(DISTINCT ...) to single-argument aggregates is removed. However, there is still a separate code path for aggregates that use DISTINCT or ORDER BY with only one input column, for performance reasons. If a non-default ordering operator is used in combination with DISTINCT, then the notion of "equality" used for the DISTINCT comparisons is the one that belongs to the ordering, rather than the default. -- Andrew. aorder-20091113.patch.gz Description: agg order by patch -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] next CommitFest
On Thu, Nov 12, 2009 at 9:15 PM, Bruce Momjian wrote: > Robert Haas wrote: >> 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 develop again. >> >> >> >> Is it really impolite for a first-contributor, no? >> >> >> > >> > I don't think so, as long as it's properly explained. >> >> Personally, I would not propose to impose this rule of first-time >> contributors, or even second-time contributors. But by about patch #3 >> I think everyone should be pitching in. > > I hate to ask, but how would we enforce this? Do we no longer apply > patches for 3rd-time submitters who have not reviewed? That seems to be > hurting us more than them. Are we prepared to discard valid patches > for this reason? We just wouldn't assign round-robin reviewers to such patches. If someone wants to volunteer, more power to them, but we would encourage people to focus their efforts on the patches of people who were themselves reviewing. It's important to keep in mind that "valid" is not a boolean. Some patches are perfect the day they roll in, but not too many. It takes work to get them committable, and I don't see why anyone should have an expectation that they can have that help for themselves without doing the same thing for other people. All that having been said, the real shortage ATM is of committers rather than reviewers. We have plenty of them, but many of them commit almost nothing. I don't want to minimize the contributions of the non-Tom committers, but Tom is numerically far and away committing more than anyone else, and not small patches, either. Beyond the fact that it makes the CommitFest slow, long, and not too much fun for Tom, it also means that Tom has less time available to do things that Only Tom Can Do. I venture to say that there will be Great Excitement about the enhancements to the EPQ machinery and PL/pgsql that Tom has recently effected. Well, if Tom hadn't had to single-handedly handle so many patches last CF, maybe he would have done something else cool, too. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] write ahead logging in standby (streaming replication)
On Fri, Nov 13, 2009 at 2:37 AM, Fujii Masao wrote: > Umm... what is your definition of "synchronous"? I'm planning to provide > four synchronization modes as follows, for v8.5. Does this fit in your I think my definition would be that a query against the replica will produce the same result as a query against the master -- and that that will be the case even after a system failure. That might not necessarily mean that the log entry is fsynced on the replica, only that it's fsynced in a location where the replica will have access to it when it runs recovery. I do have a different question though. What do you plan to do if there's a failure when they're out of sync? The master hasn't responded to the commit yet because it's still waiting on the replica to respond but it has already recorded the commit itself. When it comes back up it's out of sync with the replica and has to resend those records? What if the replica has already received it and it was the confirmation which was lost? -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Thu, Nov 12, 2009 at 9:40 PM, Bruce Momjian wrote: > daveg wrote: >> On Fri, Nov 13, 2009 at 02:22:01AM +, Greg Stark wrote: >> > >> > Really I think you guys are on the wrong track trying to map Postgres >> > releases to commercial support terms. None of the Postgres releases >> > are "supported" in the sense that there's no warranty and no promises, >> > it's all best effort. If you want a promise of anything then pay >> > someone for that service. >> > >> > As with any open source software if you're running 7-year-old versions >> > of the software you can't seriously expect the developers to take any >> > interest in bugs you discover which don't affect current releases. >> > Other projects don't release back branches at all. The most the >> > developers are likely to do if your bugs require serious engineering >> > is declare that the version you're using is too old. >> >> Claiming to support versions that are "too old" is giving users a false >> sense of comfort. Encouraging users to use these versions is actually >> harming them as when this happens they will be stuck with either living >> with the bug or doing an immediate unplanned upgrade. >> >> I suggest we announce now that both 7.4 and 8.0 will EOL when 8.5 is expected >> to ship, or to comfort those who never use .0 versions when 8.5.1 ships. > > I question whether it makes sense to EOL a version just to encourage > people to upgrade --- that logic really seems beyond our scope. It > might be practical to do it, but I see it taking us in a direction that > we might want to avoid. I don't agree with "because we want to force people to upgrade", but I do agree with Dave Gould's point about giving a false sense of comfort (I made this same point upthread somewhere, I think). ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Fri, Nov 13, 2009 at 2:35 AM, daveg wrote: > I suggest we announce now that both 7.4 and 8.0 will EOL when 8.5 is expected > to ship, or to comfort those who never use .0 versions when 8.5.1 ships. What would this mean? How would it be different than the status quo? -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
daveg wrote: > On Fri, Nov 13, 2009 at 02:22:01AM +, Greg Stark wrote: > > > > Really I think you guys are on the wrong track trying to map Postgres > > releases to commercial support terms. None of the Postgres releases > > are "supported" in the sense that there's no warranty and no promises, > > it's all best effort. If you want a promise of anything then pay > > someone for that service. > > > > As with any open source software if you're running 7-year-old versions > > of the software you can't seriously expect the developers to take any > > interest in bugs you discover which don't affect current releases. > > Other projects don't release back branches at all. The most the > > developers are likely to do if your bugs require serious engineering > > is declare that the version you're using is too old. > > Claiming to support versions that are "too old" is giving users a false > sense of comfort. Encouraging users to use these versions is actually > harming them as when this happens they will be stuck with either living > with the bug or doing an immediate unplanned upgrade. > > I suggest we announce now that both 7.4 and 8.0 will EOL when 8.5 is expected > to ship, or to comfort those who never use .0 versions when 8.5.1 ships. I question whether it makes sense to EOL a version just to encourage people to upgrade --- that logic really seems beyond our scope. It might be practical to do it, but I see it taking us in a direction that we might want to avoid. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] write ahead logging in standby (streaming replication)
On Fri, Nov 13, 2009 at 11:15 AM, Greg Smith wrote: > Whether or not you think it's sufficient for what you have in mind, > "synchronous replication" requires a return ACK from the secondary before > you say things are committed on the primary. If you don't do that, it's not > true sync replication anymore; it's asynchronous replication. Plenty of > people decide that a local commit combined with a promise to synchronize as > soon as possible to the slave is good enough for their apps, which as you > say is getting referred to as "semi-synchronous replication" nowadays. > That's an awful name though, because it's not true--that's asynchronous > replication, just aiming for minimal lag. It's OK to say that's what you > want, but you can't say it's really a synchronous commit anymore if you do > things that way. Umm... what is your definition of "synchronous"? I'm planning to provide four synchronization modes as follows, for v8.5. Does this fit in your thought? The primary waits ... before returning "success" of a transaction; * nothing - asynchronous replication * recv ACK - semi-synchronous replication * fsync ACK - semi-synchronous replication * redo ACK - synchronous replication Or, in synchronous replication, we must wait a fsync and a redo ACK? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Fri, Nov 13, 2009 at 02:22:01AM +, Greg Stark wrote: > > Really I think you guys are on the wrong track trying to map Postgres > releases to commercial support terms. None of the Postgres releases > are "supported" in the sense that there's no warranty and no promises, > it's all best effort. If you want a promise of anything then pay > someone for that service. > > As with any open source software if you're running 7-year-old versions > of the software you can't seriously expect the developers to take any > interest in bugs you discover which don't affect current releases. > Other projects don't release back branches at all. The most the > developers are likely to do if your bugs require serious engineering > is declare that the version you're using is too old. Claiming to support versions that are "too old" is giving users a false sense of comfort. Encouraging users to use these versions is actually harming them as when this happens they will be stuck with either living with the bug or doing an immediate unplanned upgrade. I suggest we announce now that both 7.4 and 8.0 will EOL when 8.5 is expected to ship, or to comfort those who never use .0 versions when 8.5.1 ships. -dg -- David Gould da...@sonic.net 510 536 1443510 282 0869 If simplicity worked, the world would be overrun with insects. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Listen / Notify rewrite
and we should stop. The world contains infinite amounts of lameness, but that's the world's problem, not ours. There is zero evidence that +1 this feature is only useful for stupid purposes, and some evidence (namely, the opinions of esteemed community members) that it is useful for at least some non-stupid purposes. The unexpected application of a feature can be creative or innovative, which I firmly believe is something this community embraces. How many ways can a screw driver be used ... think MacGyver :) Deteriming whether it's creative vs. stupid would require an understanding of the context in which it was applied. For example, using our screw driver to remove a splinter would be rather stupid, IMHO ;) -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Thu, Nov 12, 2009 at 11:16 PM, Greg Sabino Mullane wrote: >> And yes, i'm +1 for having a rule for EOL, like "5 versions are >> supported". > > If we released on a consistent schedule, this *might* be possible. > But we don't, so we can't say something like this. We've already done this. I think we said three years but I'm too lazy to go search right now. It's as meaningless now as it was then. The reality is we back branch as far back as is convenient and stop when we run into a major problem that isn't fixable in old versions. 7.4 and even 8.0 are already "EOL" in the sense that they're past your arbitrary cutoff and there's no guarantee that we'll keep releasing fixes but there's no particular reason to stop yet. Really I think you guys are on the wrong track trying to map Postgres releases to commercial support terms. None of the Postgres releases are "supported" in the sense that there's no warranty and no promises, it's all best effort. If you want a promise of anything then pay someone for that service. As with any open source software if you're running 7-year-old versions of the software you can't seriously expect the developers to take any interest in bugs you discover which don't affect current releases. Other projects don't release back branches at all. The most the developers are likely to do if your bugs require serious engineering is declare that the version you're using is too old. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] write ahead logging in standby (streaming replication)
On Fri, Nov 13, 2009 at 10:58 AM, Aidan Van Dyk wrote: > * Fujii Masao [091112 20:52]: > >> Personally, I think >> that >> semi-synchronous replication is sufficient for HA. > > Often, but that's not synchronous replication so don't call it such... Hmm, though I'm not sure about your definition of "synchronous", if the primary waits for a *redo* ACK from the standby before returning a "success" of a transaction to a client, you can call SR synchronous? This is one of TODO items of SR for v8.5. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] next CommitFest
Robert Haas wrote: > 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 develop again. > >> > >> Is it really impolite for a first-contributor, no? > >> > > > > I don't think so, as long as it's properly explained. > > Personally, I would not propose to impose this rule of first-time > contributors, or even second-time contributors. But by about patch #3 > I think everyone should be pitching in. I hate to ask, but how would we enforce this? Do we no longer apply patches for 3rd-time submitters who have not reviewed? That seems to be hurting us more than them. Are we prepared to discard valid patches for this reason? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] write ahead logging in standby (streaming replication)
Fujii Masao wrote: Personally, I think that semi-synchronous replication is sufficient for HA. Whether or not you think it's sufficient for what you have in mind, "synchronous replication" requires a return ACK from the secondary before you say things are committed on the primary. If you don't do that, it's not true sync replication anymore; it's asynchronous replication. Plenty of people decide that a local commit combined with a promise to synchronize as soon as possible to the slave is good enough for their apps, which as you say is getting referred to as "semi-synchronous replication" nowadays. That's an awful name though, because it's not true--that's asynchronous replication, just aiming for minimal lag. It's OK to say that's what you want, but you can't say it's really a synchronous commit anymore if you do things that way. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch committers
On Thu, Nov 12, 2009 at 8:55 PM, Greg Smith wrote: > I'm not sure that's the message you want to be sending, because anyone who > dreams of being a committer is going to stay as far away from doing review > as they can if that notion spreads. To say nothing of CommitFest management. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] write ahead logging in standby (streaming replication)
* Fujii Masao [091112 20:52]: >Personally, I think > that > semi-synchronous replication is sufficient for HA. Often, but that's not synchronous replication so don't call it such... -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] Listen / Notify rewrite
On Thu, Nov 12, 2009 at 8:44 PM, Josh Berkus wrote: > On 11/12/09 8:30 AM, 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. > > Sure, people will abuse it as a queue. But people abuse arrays when > they should be using child tables, use composite types to make data > non-atomic, and use dblink when they really should be using schema. > Does the potential for misuse mean that we should drop the features? No. I agree. We frequently reject features on the basis that someone might do something stupid with them. It's lame and counterproductive, and we should stop. The world contains infinite amounts of lameness, but that's the world's problem, not ours. There is zero evidence that this feature is only useful for stupid purposes, and some evidence (namely, the opinions of esteemed community members) that it is useful for at least some non-stupid purposes. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch committers
Tom Lane wrote: While I'm not against promoting more committers to deal with the influx of patches, the only way I know for people to get to the skill level of being fully competent reviewers is to have done a lot of patch writing themselves. The dynamic going on right now is that many people who might otherwise be writing their own patches are instead doing patch review to try and keep the project as a whole moving forward. I actually had two off-list discussions about that just today, that topic pops up pretty regularly as I talk with contributors at all levels. Since most people have an upper limit on how much community time they can spend, every minute spent reviewing is one you're not working on your own patches during. The way you're describing the qualification process, it would be easy to conclude that there's a reviewer ladder, and a developer ladder, and only climbing the latter leads to being a committer--that no matter how much review you do, it doesn't really count as a committer grade skill. I'm not sure that's the message you want to be sending, because anyone who dreams of being a committer is going to stay as far away from doing review as they can if that notion spreads. Based on the growing frustration with "doing review doesn't leave me with time for my own patches" I keep hearing, that perception is already something to be wary of. If the primary criteria is generating patches that apply with minimal changes, you could make a case that someone who's gotten skilled enough as a reviewer to only pass through patches of that quality should get some recognition even if they didn't write them. That's clearly a useful subset of the skills needed to commit patches only if they look to be ready for it. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] write ahead logging in standby (streaming replication)
On Fri, Nov 13, 2009 at 1:49 AM, Greg Smith wrote: > This a distressingly common thing people get wrong about replication. You > can either have synchronous replication, which as you say has to be slow: > you must wait for an fsync ACK from the secondary and a return trip before > you can say something is committed on the primary. Or you can get better > performance by not waiting for all of those things, but the minute you do > that it's *not* synchronous replication anymore. You can't get > high-performance and true synchronous behavior; you have to pick one. The > best you can do if you need both is work on accelerating fsync everywhere > using the standard battery-backed write cache technique. I'm not happy that such frequent fsyncs would harm even semi-synchronous replication (i.e., you must wait for a *recv* ACK from the secondary and a return trip before you can say something is committed on the primary. This corresponds to the DRBD's protocol B) rather than synchronous one. Personally, I think that semi-synchronous replication is sufficient for HA. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] New VACUUM FULL
Alvaro Herrera wrote: > 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. It's a good idea. I separated the part into the attached patch. It replaces VacuumStmt's "vacuum", "full", "analyze", and "verbose" fields into one "options" flag field. The only user-visible change is to support "VACUUM (options)" syntax: VACUUM ( FULL, FREEZE, VERBOSE, ANALYZE ) table (columns) We don't bother with the order of options in this form :) There is a debatable issue that we can use "VACUUM (VERBOSE) table (col)" in the abobe syntax. Columns are specified but no ANALYZE option there. An ANALYZE option is added automatically in the current implementation, but we should have thrown an syntax error in such case. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center vacuum-options_20091113.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch committers
Josh Berkus wrote: > paying attention to and which they shouldn't. I *thought* that Bruce > was doing that for AsterData, but apparently not. Josh, two days ago you complained I that I mentioned 'search_path' when we were talking about postgresql.conf, now you have another complaint about me. Did you get appointed network nanny recently? I never got that email. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Listen / Notify rewrite
On 11/12/09 8:30 AM, 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. Sure, people will abuse it as a queue. But people abuse arrays when they should be using child tables, use composite types to make data non-atomic, and use dblink when they really should be using schema. Does the potential for misuse mean that we should drop the features? No. Payloads are also quite useful even in a lossy environment, where you understand that LISTEN is not a queue. For example, I'd like to be using LISTEN/NOTIFY for cache invalidation for some applications; if it misses a few, or double-counts them, it's not an issue. However, I'd like to be able to send message like players_updated|45321 where 45321 is the ID of the player updated. --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Python 3.1 support
On Nov 12, 2009, at 12:54 PM, Peter Eisentraut wrote: > Here's the patch to support Python >=3.1 with PL/Python. :\ I was hoping to be able to use Python 3 to draw a clear distinction between plpython and the would-be "plpython3" that I've been working on. I understand that you're not in favor of a brand new implementation for Python 3. Despite my dislike for that position(well, it would seem to be in opposition to my initiative, so naturally =), I don't entirely disagree with your rationale[wrt doing things more incrementally]. For me, plpython has never been what I would call a pleasure to use, and many of the gripes that I have with it are, IMO, entrenched far enough into the implementation that any efforts to change it would(should? =) cause unacceptable breakage in user applications(?). Well, as far as additional Python interfaces are concerned, a lot of redundant functionality, but that's not even the half of it. [I was hoping to get to a status message this weekend, but it seems like I should follow-up here. =] So here's where I'm at: -- Mostly documentation improvements since I last pinged -hackers. Still, *sigh*, filling in documentation and fighting bugs as I go. Currently resolving a bug instantiating MD arrays from nested lists. Once I'm "finished" with the docs, I'm going to start looking for refcount leaks. No major additions or changes are planned, but I have been making some minor additions as I write more docs. Overview/Features: http://wiki.postgresql.org/wiki/WIP:plpython3 Documentation: http://python.projects.postgresql.org/pldocs/plpython3.html git repo[see the plpython3 branch]: http://git.postgresql.org/gitweb?p=plpython3.git;a=summary Most of the documented interfaces have tests. I only have two platforms at my disposal, so I do fear that this will not "just work" on all of PG's supported platforms. Specifically, I've ran the tests on freebsd/amd64 and Mac10.6/intel(of course 10.5 as well for some earlier revisions). [err, actually, it's been a while since I ran the tests on freebsd.] -- plpython3 is turning out to be kinda beefy(~974K diff[eh, there is some fluff in there]), and I can't say that I've seen much interest in it, so I can't really blame anyone if -hackers ends up taking a pass on it. (python3 is too far away for most folk to care? folk are content with plpython?) eh, cheers, either way. =) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch committers
On Thu, Nov 12, 2009 at 6:53 PM, Tom Lane wrote: > Now those criteria were developed to deal mainly with people committing > their own patches. What we have at the moment is a lot of patches > coming in from people who aren't ready to be committers, and maybe don't > ever want to be. The question is how to do an adequate job of reviewing > their patches, when only a fraction of the existing committers are > willing to put time into reviewing other people's patches. (Let's face > it, that's a lot less fun than writing your own code.) I kind of like reviewing, actually. It's a good way to get familiar with new parts of the code. That's part of the coolness of open source: other people do a lot of your work for you. Of course, that doesn't mean I would want to ONLY review other people's patches and never write any of my own. > While I'm not > against promoting more committers to deal with the influx of patches, > the only way I know for people to get to the skill level of being fully > competent reviewers is to have done a lot of patch writing themselves. > > Years ago, somebody (I think one of the original Berkeley crew) remarked > "this project doesn't need a lot of people with a little time, it needs > a few people with a lot of time". I'm afraid that's still true, and > it's still hard to find those people. No, I think it's hard to find those people's salaries. I feel like I've managed a fairly good stream of patches given that this is something I do mostly between 8 PM and midnight after working a full day and in between other things that I need to get done, but if I were getting paid to hack on PostgreSQL full time (or even one or two days a week) that stream would be a whole lot bigger. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch committers
"Kevin Grittner" writes: > 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? He hasn't actually written all that much *code* ... yet, anyway. Historically, we've promoted people to being committers when (a) the existing committers got tired of applying patches from them and (b) their patches were usually going in without significant modification. (a) speaks to whether you do enough work regularly enough that there's actually a benefit to the project from giving you the keys to the car, and (b) speaks to whether you're ready in terms of technical knowledge of the code base. (I'm not saying you have to be competent in the whole PG code base, just whatever part you like to work on.) Now those criteria were developed to deal mainly with people committing their own patches. What we have at the moment is a lot of patches coming in from people who aren't ready to be committers, and maybe don't ever want to be. The question is how to do an adequate job of reviewing their patches, when only a fraction of the existing committers are willing to put time into reviewing other people's patches. (Let's face it, that's a lot less fun than writing your own code.) While I'm not against promoting more committers to deal with the influx of patches, the only way I know for people to get to the skill level of being fully competent reviewers is to have done a lot of patch writing themselves. Years ago, somebody (I think one of the original Berkeley crew) remarked "this project doesn't need a lot of people with a little time, it needs a few people with a lot of time". I'm afraid that's still true, and it's still hard to find those people. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Listen / Notify rewrite
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Tom Lane writes: > 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 used as a condition signal. I don't want "large" but I do think an arbitrary limit of 128 is odd without some justfication. I could do 128, but would probably be happier with a bit more room. > 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 client crash is OK for a condition notification, > not so OK for a message queue. The difference is that the former style > assumes that the authoritative data is in a table somewhere, so you can > still find out what you need to know after reconnecting. If you are > doing messaging you are likely to think that you don't need any backing > store for the system state. That's putting an awful lot of assumptions on what people are going to do in the future, and also not being imaginative enough for circumstances in which a payload which is not system crash survivable is a completely acceptable condition. In most of my use cases, even desired. People wanting a real queue can continue to use something other than NOTIFY. > 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. Absolutely is a good idea. Agent M asks: > The notification count could be a secondary "payload" which does not > affect the first, but I guess I'm the only one complaining about the > coalescing... Er...this thread is only a few hours old. For the record, I'm fine with the coalescing as we do now (at least as far as my own selfish purposes :) - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 200911121836 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkr8nCwACgkQvJuQZxSWSsjQIgCgjH60LlZYEek9FwcD+/w4IHYQ PWwAnR0YxdSBm5iBa+G+T1VpIP4qjJsx =Ju0P -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Application name patch - v3
Hi Dave,
On Thursday 22 October 2009 15:07:13 Dave Page wrote:
> Updated patch attached. Per discussion, this:
> - Changes the envvar name to PGAPPNAME
> - Removes support for setting application_name in the startup packet,
> and instead sends an explicit SET command as part of the connection
> setup in PQconnectPoll. In order to avoid adding to the
> application-visible connection states, this is overloaded on the
> CONNECTION_SETENV state which is only used in the v2 protocol at
> present and seems like an ideal fit for such a similar use.
I had some free time so I started to take a look at that patch:
+ PostgresPollingStatusType
+ pqAppnamePoll(PGconn *conn)
...
+ case APPNAME_STATE_OPTION_WAIT:
...
+ else
+ {
+ /* Query finished, so we're done */
+ conn->setenv_state = APPNAME_STATE_IDLE;
+ return PGRES_POLLING_OK;
+ }
+ break;
+ }
Shouldnt that set appname_state?
The attached patch fixes this and also a couple occurances of trailing
whitespace.
What about pg_dump/psql setting fallback_application_name?
Andres
From 962861a38ea28c769bb28c18f3142f0339e97f5c Mon Sep 17 00:00:00 2001
From: Andres Freund
Date: Fri, 13 Nov 2009 00:28:44 +0100
Subject: [PATCH] Dave Page: Application name patch - v3
---
doc/src/sgml/config.sgml | 16 +++
doc/src/sgml/libpq.sgml | 37 +
doc/src/sgml/monitoring.sgml | 12 +-
src/backend/catalog/system_views.sql |3 +-
src/backend/postmaster/pgstat.c | 56 ++--
src/backend/utils/adt/pgstatfuncs.c | 16 ++-
src/backend/utils/error/elog.c| 16 +++
src/backend/utils/misc/guc.c | 11 ++
src/backend/utils/misc/postgresql.conf.sample |1 +
src/include/catalog/pg_proc.h |2 +-
src/include/pgstat.h |4 +
src/include/utils/guc.h |2 +
src/interfaces/libpq/fe-connect.c | 177 -
src/interfaces/libpq/libpq-int.h | 12 ++
src/test/regress/expected/rules.out |2 +-
15 files changed, 338 insertions(+), 29 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index eb2071f..87e6dac 100644
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
*** local0.*/var/log/postgresql
*** 2881,2886
--- 2881,2901
+ application_name (string)
+
+application_name configuration parameter
+
+
+
+ The application_name is typically set by an
+ application upon connection to the server. The value will be included
+ in CSV logs and may be included in the log_line_prefix.
+ In addition, it will be included in the pg_stat_activity view.
+
+
+
+
+
debug_print_parse (boolean)
debug_print_rewritten (boolean)
debug_print_plan (boolean)
*** CREATE TABLE postgres_log
*** 3325,3330
--- 3340,3346
query text,
query_pos integer,
location text,
+ application_name text,
PRIMARY KEY (session_id, session_line_num)
);
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 86affb0..e4576e6 100644
*** a/doc/src/sgml/libpq.sgml
--- b/doc/src/sgml/libpq.sgml
***
*** 249,254
--- 249,281
+
+ application_name
+
+
+Allows an application to specify a value for the application_name
+ configuration variable, the value of which may be included in logging
+ output and monitoring data from views such as pg_stat_activity.
+
+
+
+
+
+ fallback_application_name
+
+
+Allows an application to specify a fallback value for the
+ application_name configuration variable. This value
+ is used if neither the application_name connection
+ string option or PGCLIENTENCODING are set,
+ which offers the application a way to allow the enviroment to
+ override a compiled in default. This is useful when scripting
+ generic utilities to perform specific tasks where a bespoke
+ application name is desirable.
+
+
+
+
tty
*** myEventProc(PGEventId evtId, void *evtIn
*** 5785,5790
--- 5812,5827
+PGAPPNAME
+
+ PGAPPNAME behaves the same as connection parameter.
+
+
+
+
+
+
PGSSLMODE
PGSSLMODE behaves the same as user ID, user OID, user name, current query,
Re: [HACKERS] EOL for 7.4?
On Thu, 2009-11-12 at 23:16 +, Greg Sabino Mullane wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: RIPEMD160 > > > >> needs significant preparation for them. Announcing an EOL early in time > >> would give them the required time before the version used disappears. > > > > So, should we announce it for June? > > No, it should be longer. June is practically around the corner > as far as business planning is concerned. Make it a year. Since it's > mid November, why not just say 2011? If a business wants support they can buy it. There is no reason for this community to continue supporting it. > > > And yes, i'm +1 for having a rule for EOL, like "5 versions are > > supported". > > If we released on a consistent schedule, this *might* be possible. > But we don't, so we can't say something like this. > We can say 5 "years" from release though. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering If the world pushes look it in the eye and GRR. Then push back harder. - Salamander -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 >> needs significant preparation for them. Announcing an EOL early in time >> would give them the required time before the version used disappears. > > So, should we announce it for June? No, it should be longer. June is practically around the corner as far as business planning is concerned. Make it a year. Since it's mid November, why not just say 2011? > And yes, i'm +1 for having a rule for EOL, like "5 versions are > supported". If we released on a consistent schedule, this *might* be possible. But we don't, so we can't say something like this. - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 200911121815 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkr8lykACgkQvJuQZxSWSsi6xACdHU7xKgsfG+/zE2StXp97mdjC XGoAn3LvIjzh1RKmD9K0Zyrg9W3LuHxt =jCVo -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] actualised funcs typmod patch
Pavel Stehule escribió: > Hello > > actualised version: enhance check inside sql function What is this against? It has a few suspicious chunks, such as *** *** 358,364 funcexpr->funcid = funcid; funcexpr->funcresulttype = rettype; ! funcexpr->funcresulttypmod = -1; // TODO STEHULE funcexpr->funcretset = retset; funcexpr->funcformat = COERCE_EXPLICIT_CALL; funcexpr->args = fargs; --- 365,371 funcexpr->funcid = funcid; funcexpr->funcresulttype = rettype; ! funcexpr->funcresulttypmod = rettypmod; funcexpr->funcretset = retset; funcexpr->funcformat = COERCE_EXPLICIT_CALL; funcexpr->args = fargs; This ended up in ./src/backend/parser/parse_func.c.rej There are other rejects and I'm not sure if I should fix them (at least the first couple look trivial, though it's against a bunch of code that last changed in Aug. last year) or ask for a better version ... -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance
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 >> optimizing it. > When I looked at doing this, I thought about just using check > constraints just for the book keeping and leaving attnotnull as it is. Yeah, you could definitely attack it like that. The code that fixes up attnotnull would have to look for check constraints that look like "foo NOT NULL" rather than something more instantly recognizable, but presumably ALTER TABLE is not a performance-critical path. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch committers
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 seem to be more about the related topic of drawing in new contributors... Robert Haas wrote: > Josh Berkus wrote: >> >>> That's basically just it: Assume bashing is part of the process. >> I've heard this complaint from numerous first-time contributors, >> and have seen several talented people walk away from our project >> because of it. Even people who have stuck with us, such as Josh >> Tolley, have remarked on the "hazing ritual" inherent in getting a >> first-time contribution in. > > 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. I would say that I don't often see anything I would consider as "bashing", but that I have seen newcomers who appeared to want to help contribute to the project handled with less finesse than one could perhaps expect. It seems to me that those needing assistance (especially if they are in dire straights or are trying to convert to PostgreSQL) are treated very gently. Someone with a question, if it isn't something too obviously documented in the FAQ or the online manual, is given a polite and informative response. The responses get pretty blunt if the person offers suggestions which show that the person has (or assumes) technical competence, when those suggestions aren't acceptable to the community. At that point it takes a pretty thick skin to find some other way to contribute, rather than just walking away. Again, I wouldn't call it bashing, but a level of bluntness which could be disconcerting if the person hasn't followed these lists long enough to understand how it is intended. > When someone submits a bad patch and I review it, they sometimes get > two or three pages of feedback detailing inadequacies of various > types. When done in a professional manner, which is typical of this list, I don't think there's any reasonable alternative. I don't see that as a problem. Well, there is one thing which must be frustrating. If I was seated near others who read this list, I would start a pool every time a newcomer submitted a large patch -- how long until someone tells them to break it into smaller patches, and how long until someone else tells them it makes no sense separated like that and should be put back together? >> the only possible solution is for each new contributor to have a >> mentor who sticks with them throughout the process of getting their >> first contribution accepted I don't know how common it is, but I felt that Bruce did that for me when I worked on the standard_conforming_strings TODO item for 8.2. (Perhaps part of the reason was that it was urgently needed to address problems we found in production after we converted a critical database to PostgreSQL; but whatever the reason, I was grateful for the help.) Having gone through that experience, I feel confident that such assistance for first-time contributors can make a difference both in the success of their efforts (which will then, presumably, benefit the community in general) and in their willingness to contribute in other ways. >> It would also help if people on this list *in general*, were to be >> a bit more consistent about phrasing criticism as constructive >> criticism. I've seen far too much "how stupid are you?" on this >> list for the good health of our developer community. > > I don't see very much of this at all, so maybe this is another area > where it boils down to perspective. I don't see much of that either, although describing another's statement as "nonsense" or something similar isn't unheard of. It's not usually an unfair characterization, but some could take such bluntness as hostility. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance
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 this, I thought about just using check constraints just for the book keeping and leaving attnotnull as it is. If would be easier, but it seemed quite ugly. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] plpgsql GUC variable: custom or built-in?
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, but so what? True, but on the other hand, if plpgsql needs this to work nicely, then $YOURPL probably needs it too. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
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 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 upgrade. > > >> > > > > > > I know several customers who decided to move from 7.3 only after the > > > EOL was announced. If 7.3 would not has see an EOL, they would never > > > ever have moved to a newer version. > > > > > > > > > Nobody that I have seen is arguing against EOLing 7.4. > > True. But as Josh pointed out: some people/projects/companies need > more "motivation" to actually consider an upgrade at all. We have discussed in the past EOLing 7.4 I thought at the end of this year. IMO 7.4 and 8.0 both need to be EOL. Can we just set a date and call it good? March 31st sounds good. Let's write up a quick announcement, add the letters EOL to the download pages and call it good. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering If the world pushes look it in the eye and GRR. Then push back harder. - Salamander -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] plpgsql GUC variable: custom or built-in?
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 of the system is not completely true anyway. Yes, we're playing favorites in the PL camp here, but so what? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
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 their users an > >> upgrade path (Gnuworld comes to mind). They need an EOL announcement to > >> get them motivated to upgrade. > >> > > > > I know several customers who decided to move from 7.3 only after the > > EOL was announced. If 7.3 would not has see an EOL, they would never > > ever have moved to a newer version. > > > > > Nobody that I have seen is arguing against EOLing 7.4. True. But as Josh pointed out: some people/projects/companies need more "motivation" to actually consider an upgrade at all. > 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 prepare for an EOL months or a year in advance, ISTM. Months. The software will not stop working once we announced the EOL. And yes, i'm +1 for having a rule for EOL, like "5 versions are supported". Bye -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_dump enhancement proposal
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. Custom Query Exports > In my use of mysqldump, I found one feature very useful: the ability > to execute a custom SELECT. . .WHERE statement and then dump only the > results. This feature currently provides MySQL users with the ability > to quickly and easily export very granular data subsets, and I see no > reason why PostgreSQL users wouldn't benefit from the same capability. > While it is true that this functionality can already be achieved in > PostgreSQL using Copy, it seems to me that it would logically fit well > as an extension to pg_dump, especially since many beginning and even > some intermediate PostgreSQL users aren't aware of the alternatives. As you say, we already have this using COPY, and I don't agree that it would be a good idea to plaster it into pg_dump as well. pg_dump is intended for dumping and restoring data, not for ETL-type tasks. Furthermore, pg_dump is a overly complex beast already --- much more so than one could wish, for a tool that is absolutely fundamental to database reliability. Putting requirements on it that are well outside its charter seems like a short route to maintenance disaster. There has been some occasional chatter about developing one or more tools focused on ETL rather than dump/restore, and my thought is that this idea would fit better there. An ETL tool would not have the kind of requirements pg_dump has for coping with multiple server versions and knowing everything there is to know about database contents, so it seems like it could address new areas of functionality without a complexity explosion. You might want to check the archives for previous discussions --- I think the last go-round started with someone wanting to add an arbitrary WHERE filter to pg_dump dumps. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] CommitFest 2009-11 Call for Reviewers
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 probably not too much general feedback left anyway. I just marked all of those as having Michael as the reviewer. If it gets to where those are the main remaining hold-up I guess we'll revisit who else might help out then. Would rather get the patches it's more obvious how to handle out of the way first. Not considering those, HS/SR, or other patches with an already assigned reviewer, we're at 16 patches in the queue, and I've got 9 reviewer volunteers just so far today. Barring a flood of last-minute entries, if I can get each reviewer to handle one patch and a moderate percentage of them to handle two, that should be all it takes for this round. Will move the rest of the discussion here to just rrreviewers. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cvs head doesn't pass make check on one of the machines here
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 make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cvs head doesn't pass make check on one of the machines here
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 a clue as to what you're doing wrong ... cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] next CommitFest
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 frustrating and less productive for >> > them. An important part of review is to read the relevant mailing list >> > threads and try to tie up loose ends and find a consensus. >> >> Unfortunately, those people's patches also typically require more work >> from other community members. Discussions are longer and more >> confused, and someone has to rewrite the documentation and comments >> before commit. If anything, people whose patches require more help >> need to find ways to contribute MORE to the community, not less. I >> understand that's not easy, but it's necessary. > > Keep in mind that many of these people may also be regional contacts, > translators, local conference (or user group) organizers, and provide > support to users in languages other than English. They may even organize > development efforts in languages other than English. They may, but it's beyond my power to keep track of everything that a person may or may not do. If we're going to have any chance of enforcing a policy, it has to be simple and clear. > I don't have a good answer for that. But sometimes the policy > discussions here seem a little abstract, and I have a hard time seeing > how they apply in real situations. It seems like you have a few > "freeloaders" in mind, but I have a hard time imagining it's more than a > couple people. Maybe they just need a nice reminder to be a more helpful > community member if they want timely feedback on their work? Well, you can go back and look at the list of people who had patches reviewed last CF (see commitfest.postgresql.org), and then go back and look at the reviewers (see pgsql-rrreviewers archives). It's all public data. It's not 1 or 2 people - I count at least 8. I could cross-reference for you and list the names, but that seems like embarassing those people without accomplishing anything useful. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Python 3.1 support
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 could be available in parallel with plpython 2, because of the user-level coding incompatibilities. It looks like this patch simply ignores that problem. What is going to happen to plpython functions that depend on 2.x behavior? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance
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 need to track all changes > in pg_constraint and keep pg_attribute.attnotnull up to date. > Another possibility is to change the representation of NOT NULL to be a > CHECK constraint (e.g. CHECK(col IS NOT NULL)) internally and leave all the > responsibility up to the current existing check constraint infrastructure > (which already does the right thing for inheritance, e.g. it's not possible > to drop such a constraint if it was inherited). 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. Furthermore, removing attnotnull would break an unknown but probably not-negligible amount of client-side code that cares whether columns are known not null (I think both JDBC and ODBC track that). And it would significantly complicate code in the backend that wants to determine whether a column is known not null --- there are several proposals for planner optimizations that would depend on knowing that, for example. You will find yourself copying-and-pasting a fair amount of the check-constraint code if you implement this as a completely separate code path, and so it might be worthwhile to be creative about exactly what the pg_constraint representations look like --- maybe you can design it to share some of that code. But I recommend strongly that attnotnull stay there. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] cvs head doesn't pass make check on one of the machines here
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
Re: [HACKERS] EOL for 7.4?
> 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 give them the required time before the version used disappears. So, should we announce it for June? --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
--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 prepare for an EOL months or a year in advance, ISTM. 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 give them the required time before the version used disappears. -- Thanks Bernd -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
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 announcement to get them motivated to upgrade. I know several customers who decided to move from 7.3 only after the EOL was announced. If 7.3 would not has see an EOL, they would never ever have moved to a newer version. Nobody that I have seen is arguing against EOLing 7.4. We'd want to do a full publicity around this, including a "how do I upgrade" page and an "what does EOL mean for an OSS project" page. If this goes well, we could EOL 8.0 after 8.5 comes out, and thus decrease our maintenance burden. +1 The only burden of significance I have seen actually mentioned, as opposed to supposed, is from Dave Page. 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 prepare for an EOL months or a year in advance, ISTM. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] next CommitFest
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 review is to read the relevant mailing list > > threads and try to tie up loose ends and find a consensus. > > Unfortunately, those people's patches also typically require more work > from other community members. Discussions are longer and more > confused, and someone has to rewrite the documentation and comments > before commit. If anything, people whose patches require more help > need to find ways to contribute MORE to the community, not less. I > understand that's not easy, but it's necessary. Keep in mind that many of these people may also be regional contacts, translators, local conference (or user group) organizers, and provide support to users in languages other than English. They may even organize development efforts in languages other than English. I think the best policies encourage people to help in the ways that they are most effective, and/or enjoy the most. I know that's a general statement, and it doesn't translate (excuse the pun) easily into policy. I don't have a good answer for that. But sometimes the policy discussions here seem a little abstract, and I have a hard time seeing how they apply in real situations. It seems like you have a few "freeloaders" in mind, but I have a hard time imagining it's more than a couple people. Maybe they just need a nice reminder to be a more helpful community member if they want timely feedback on their work? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] CommitFest 2009-09, two weeks on
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 apparently you forgot. >> >> Thanks. Your fix is correct if this patch is considered >> standalone. This means I have to re-post the later >> patches to fix the reject this fix causes in them. > > Yeah. BTW I don't think the rest of the pieces in this series make > sense to apply separately, because they don't do anything useful by > themselves (one of them introduces an unused function, what good is in > that?). I think they should be submitted as a single patch. > > If you want to submit patches in a series like this one, they need to be > considered standalone, I think. The Linux kernel devs work differently > than us here. Zoltan broke them up because Michael asked him to do so. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
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 upgrade. I know several customers who decided to move from 7.3 only after the EOL was announced. If 7.3 would not has see an EOL, they would never ever have moved to a newer version. > We'd want to do a full publicity around this, including a "how do I > upgrade" page and an "what does EOL mean for an OSS project" page. If > this goes well, we could EOL 8.0 after 8.5 comes out, and thus decrease > our maintenance burden. +1 -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch committers
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 developer. > Guess what - my development ideas are all brilliant - or at least > there's no contrary evidence! Then I come here, where there are > plenty of other developers just as smart as I am, or possibly smarter, > and here some of my ideas crash and burn. On the other hand, > sometimes someone objects to my idea and the *objections* crash and > burn. You can't expect to win them all when you're dealing with > people who are as smart as you and more knowledgeable about the code. Maybe this paragraph (and some others from this email and Josh's) should be part of the "how to submit a patch" wiki page. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Python 3.1 support
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 every
test file and also for some input files (where Python syntax had
changed), a sed script creates a complete Python 3 compatible set of
input and output files. Doesn't look pretty but works quite well. If
anyone has a better idea, please let me know.
diff --git a/src/pl/plpython/Makefile b/src/pl/plpython/Makefile
index 373bc79..840b874 100644
--- a/src/pl/plpython/Makefile
+++ b/src/pl/plpython/Makefile
@@ -88,8 +88,32 @@ installdirs: installdirs-lib
uninstall: uninstall-lib
+ifneq (,$(findstring 3.,$(python_version)))
+# Adjust regression tests for Python 3 compatibility
+prep3:
+ mkdir -p 3 3/sql 3/expected
+ for file in $(srcdir)/sql/* $(srcdir)/expected/*; do \
+ sed -r -e 's/except ([[:alpha:].]+), ?(\w+):/except \1 as \2:/g' \
+ -e "s///g" \
+ -e "s///g" \
+ -e "s/\b([0-9]+)L\b/\1/g" \
+ -e 's/\bu"/"/g' \
+ -e "s/\bu'/'/g" \
+ -e "s/def next\b/def __next__/g" \
+ $$file >`echo $$file | sed 's,$(srcdir),3,'`; \
+ done
+
+clean3:
+ rm -rf 3/
+
+installcheck: submake prep3
+ cd 3 && $(top_builddir)/../src/test/regress/pg_regress --inputdir=. --psqldir=$(PSQLDIR) $(REGRESS_OPTS) $(REGRESS)
+
+clean: clean3
+else
installcheck: submake
$(top_builddir)/src/test/regress/pg_regress --inputdir=$(srcdir) --psqldir=$(PSQLDIR) $(REGRESS_OPTS) $(REGRESS)
+endif
.PHONY: submake
submake:
diff --git a/src/pl/plpython/expected/README b/src/pl/plpython/expected/README
index 47f31e8..a187937 100644
--- a/src/pl/plpython/expected/README
+++ b/src/pl/plpython/expected/README
@@ -8,3 +8,5 @@ plpython_unicode_0.out any version, when server encoding != SQL_ASCII and clien
plpython_unicode_2.out Python 2.2
plpython_unicode_3.out Python 2.3, 2.4
plpython_unicode_5.out Python 2.5, 2.6
+
+plpython_types_3.out Python 3.1
diff --git a/src/pl/plpython/expected/plpython_types_3.out b/src/pl/plpython/expected/plpython_types_3.out
new file mode 100644
index 000..3fcb0f4
--- /dev/null
+++ b/src/pl/plpython/expected/plpython_types_3.out
@@ -0,0 +1,479 @@
+--
+-- Test data type behavior
+--
+--
+-- Base/common types
+--
+CREATE FUNCTION test_type_conversion_bool(x bool) RETURNS bool AS $$
+plpy.info(x, type(x))
+return x
+$$ LANGUAGE plpythonu;
+SELECT * FROM test_type_conversion_bool(true);
+INFO: (True, )
+CONTEXT: PL/Python function "test_type_conversion_bool"
+ test_type_conversion_bool
+---
+ t
+(1 row)
+
+SELECT * FROM test_type_conversion_bool(false);
+INFO: (False, )
+CONTEXT: PL/Python function "test_type_conversion_bool"
+ test_type_conversion_bool
+---
+ f
+(1 row)
+
+SELECT * FROM test_type_conversion_bool(null);
+INFO: (None, )
+CONTEXT: PL/Python function "test_type_conversion_bool"
+ test_type_conversion_bool
+---
+
+(1 row)
+
+-- test various other ways to express Booleans in Python
+CREATE FUNCTION test_type_conversion_bool_other(n int) RETURNS bool AS $$
+# numbers
+if n == 0:
+ ret = 0
+elif n == 1:
+ ret = 5
+# strings
+elif n == 2:
+ ret = ''
+elif n == 3:
+ ret = 'fa' # true in Python, false in PostgreSQL
+# containers
+elif n == 4:
+ ret = []
+elif n == 5:
+ ret = [0]
+plpy.info(ret, not not ret)
+return ret
+$$ LANGUAGE plpythonu;
+SELECT * FROM test_type_conversion_bool_other(0);
+INFO: (0, False)
+CONTEXT: PL/Python function "test_type_conversion_bool_other"
+ test_type_conversion_bool_other
+-
+ f
+(1 row)
+
+SELECT * FROM test_type_conversion_bool_other(1);
+INFO: (5, True)
+CONTEXT: PL/Python function "test_type_conversion_bool_other"
+ test_type_conversion_bool_other
+-
+ t
+(1 row)
+
+SELECT * FROM test_type_conversion_bool_other(2);
+INFO: ('', False)
+CONTEXT: PL/Python function "test_type_conversion_bool_other"
+ test_type_conversion_bool_other
+-
+ f
+(1 row)
+
+SELECT * FROM test_type_conversion_bool_other(3);
+INFO: ('fa', True)
+CONTEXT: PL/Python function "test_type_conversion_bool_other"
+ test_type_conversion_bool_other
+-
+ t
+(1 row)
+
+SELECT * FROM test_type_conversion_bool_other(4);
+INFO: ([], False)
+CONTEXT: PL/Python function "test_type_conversion_bool_other"
+ test_type_conversion_bool_other
+-
+ f
+(1 row)
+
+SELECT * FROM test_type_conversion_bool_other(5);
+INFO: ([0], True)
+CONTEXT: PL/Python function "test_type_conversion_bool_other"
+ test_type_conversion_bool_other
+-
+ t
+(1 row)
+
+CREATE FUNCTION test_type_conversion_char(x char) RETURNS char AS $$
+plpy.info(x, type(x))
+return x
+$$ LANGUAGE plpyt
Re: [HACKERS] array_to_string bug?
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 wondering who'd comment on that first ;) Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] CommitFest 2009-11 Call for Reviewers
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 set. Those are not so easy to > > just split among multiple people due to how they relate to one another. > > 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. If anyone really wants > to review them, of course, that's fine ... but I don't think you should > assign them to someone just because the CF process says to. FWIW I committed the parts of one of these patches that touched the core grammar mostly, because I think those might have been holding Michael back a bit. Hopefully that'll make it easier for him to review the rest. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] CommitFest 2009-09, two weeks on
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 patch is considered > standalone. This means I have to re-post the later > patches to fix the reject this fix causes in them. Yeah. BTW I don't think the rest of the pieces in this series make sense to apply separately, because they don't do anything useful by themselves (one of them introduces an unused function, what good is in that?). I think they should be submitted as a single patch. If you want to submit patches in a series like this one, they need to be considered standalone, I think. The Linux kernel devs work differently than us here. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] array_to_string bug?
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 changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] next CommitFest
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 need every patch author >> to review as many patches as they submit, because some people will >> review extras, and some non-patch-authors will review. If they review >> one patch each, that's probably more than enough. It's also easier >> for bookkeeping purposes. > > 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 review is to read the relevant mailing list > threads and try to tie up loose ends and find a consensus. Unfortunately, those people's patches also typically require more work from other community members. Discussions are longer and more confused, and someone has to rewrite the documentation and comments before commit. If anything, people whose patches require more help need to find ways to contribute MORE to the community, not less. I understand that's not easy, but it's necessary. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pg_dump enhancement proposal
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 think can make it even better: 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. 2. Custom Query Exports In my use of mysqldump, I found one feature very useful: the ability to execute a custom SELECT. . .WHERE statement and then dump only the results. This feature currently provides MySQL users with the ability to quickly and easily export very granular data subsets, and I see no reason why PostgreSQL users wouldn't benefit from the same capability. While it is true that this functionality can already be achieved in PostgreSQL using Copy, it seems to me that it would logically fit well as an extension to pg_dump, especially since many beginning and even some intermediate PostgreSQL users aren't aware of the alternatives. If the community finds value in the above features, I would be glad to begin developing them for possible inclusion in the next PostgreSQL release. Best Regards, Mark Hammonds Web Engineer OmniTI Computer Consulting technology.markhammonds.ws -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] CommitFest 2009-11 Call for Reviewers
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 easy to > just split among multiple people due to how they relate to one another. 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. If anyone really wants to review them, of course, that's fine ... but I don't think you should assign them to someone just because the CF process says to. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Check constraint on domain over an array not executed for array literals
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 *not* executed for literals of the domain-over-array-type - in other words, for expressions like: array[...]::. They are, however, executed if I first force the array to be of the base type, and then cast it to the array type. Here is an example that reproduces the problem: create domain myintarray as int[] check ( -- Check that the array is neither null, nor empty, -- nor multi-dimensional (value is not null) and (array_length(value,1) is not null) and (array_length(value,1) > 0) and (array_length(value,2) is null) ); select null::myintarray; -- Fails (Right) select array[]::myintarray; -- Succeeds (Wrong) select array[]::int[]::myintarray; -- Fails (Right) select array[1]::myintarray; -- Succeeds (Right) select array[1]::int[]::myintarray; -- Succeeds (Right) select array[array[1]]::myintarray; -- Succeeds (Wrong) select array[array[1]]::int[][]::myintarray; -- Fails (Right) I guess the reason is that the "::arraytype" part of "array[...]::arraytype" isn't really a cast at all, but instead part of the array literal syntax. Hence, array[]::myintarray probably creates an empty myintarray instance, and then adds the elements between the square brackets (none) - with none of this steps triggering a run of the check constraint. I still have the feeling that this a bug, though. First, because it leaves you with no way at guarantee that values of a given domain always fulfill certain constraints. And second because "array[...]::arraytype" at least *looks* like a cast, and hence should behave like one too. best regards, Florian Pflug smime.p7s Description: S/MIME Cryptographic Signature
Re: [HACKERS] Patch committers
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 from other FOSS projects for a few years. We lack both a benevolent dictator, or a single-corporate backer... We have an incredible reputation for technical expertise -- most knowledgeable FOSS developers fear and are in awe of the quality of code our community produces. I hear criticism for the way in which our development community operates, and how we communicate with "outsiders". But few people are able to offer concrete suggestions on /how/ we might change, as opposed to the /particular things/ that they think should change. So on this point: On Wed, Nov 11, 2009 at 7:30 PM, Emmanuel Cecchet wrote: > The commitfest started to > address some of the most obvious issues but there is probably much more that > can be done by looking at what is happening in the other open source > communities. Speaking from a cultural, and organizational standpoint: * Distributed revision control as standard for the project Using a distributed revision control system, and working from developer branches which are pulled & pushed directly between developers is consistently reported to have a positive impact on solving problems and sharing information. Summer of Code mentors consistently mention DVCS as having a huge positive impact on productivity for their students - both because it's easy and cheap for students to commit to their local repos, and because the merge/pull tools are intuitive for the mentors and students. This is how people work and share code "out there". I realize that Postgres has an established cultural norm of posting patches to the mailing list, and I'm not suggesting that people stop doing that. I think more developers should be sharing branches as well. git.postgresql.org should probably be reorganized to clearly divide repos between postgresql-core and other projects (contrib, add-ons, whatever). We should also publish more information about how our developers are sharing code with each other through repos. * Decision making Is there a project you'd point to as a model for decision making? (serious question) This is a volunteer organization, and as such, we're subject to who has the expertise + time/energy to devote to the patches and projects. Going back to what Bruce has said about skill drain -- if more individuals were able to get their time sponsored to devote to the technical challenges posed by the patches, then it might be possible to have more coordinated/streamlined responses and decision making. My experience in FOSS projects is that Postgres does fairly well on execution compared to other projects (getting a new release out the door every year, and now the alphas every couple months), but has some issues with a couple large, important patches. Part of the problem there appears to be people being stretched too thin, and inconsistent communication practices. More involvement from people really focusing on improving communication between developers would be helpful to make those issues easier to work around. * Volunteers, funding and burnout It's challenging to keep up with the technical discussions on -hackers even if you are a very knowledgeable developer. If you're only doing that on your free time, and say, you have a family? Most of the developers that I know in other projects in leadership/commit manager roles don't have young children, and very few are women. So, another thing that we could use are more people like Bruce that can devote a great deal of *work* time to thinking about and acting on the issues around community management and recruitment. Robert Haas' time spent on commitfest, for example, if sponsored by a foundation would be very helpful. Maybe he could have bought a new dishwasher. :) Also, we could use an individual dedicated to raising funds and consistently executing on distributing the money out for non-code "infrastructure" projects. Like: * release management, * marketing, * dedicated public relations (driving things like new software release articles, organizing interviews with press, and getting new case studies written), and * keeping track of our relationships with other organizations (Summer of Code, conferences, commercial forks). A lot of this work falls on Josh Berkus to coordinate. There are many more tasks, and some are delegated to others & coordinated on -advocacy. Again, this is work that could be funded through a foundation, or as part of positions in particular companies. IMO, it's about providing incentives that encourage people to use their time wisely, and to help prevent burnout on the difficult tasks around people management. And to say definitively that the people tasks require organization and management, and we as a development c
Re: [HACKERS] [RRR] CommitFest 2009-11 Call for Reviewers
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 to handle this one. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com
Re: [HACKERS] ALTER TABLE...ALTER COLUMN vs inheritance
--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 looking into this and wonder how this should look like. 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 need to track all changes in pg_constraint and keep pg_attribute.attnotnull up to date. Another possibility is to change the representation of NOT NULL to be a CHECK constraint (e.g. CHECK(col IS NOT NULL)) internally and leave all the responsibility up to the current existing check constraint infrastructure (which already does the right thing for inheritance, e.g. it's not possible to drop such a constraint if it was inherited). ALTER TABLE ... SET NOT NULL and DROP NOT NULL will be just syntactic sugar then. I don't know the original design decisions for the current representation, but it seems it wasn't essential? Of course, there's still the requirement to special case those check constraints in various places, since pg_dump and psql have to do the right thing. -- Thanks Bernd -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch committers
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 prerequisite amount of gamesmanship to the system and tune >> your bikeshedding detectors. Don't take anything personally. Live and >> learn. > > I think what Emmanuel is complaining about here ... with some > justification ... is not the revision requirements of our patch process > but the extremely confusing and frustrating nature of it for new > contributors. For example, how exactly is a new contributor supposed to > know the difference between "bikeshedding" and "constructive criticism", > when (a) they don't know the people involved, and (b) even our more > dedicated committers engage in bikeshedding periodically? > > This isn't just Emmanuel; I've heard this complaint from numerous > first-time contributors, and have seen several talented people walk away > from our project because of it. Even people who have stuck with us, > such as Josh Tolley, have remarked on the "hazing ritual" inherent in > getting a first-time contribution in. 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 developer. Guess what - my development ideas are all brilliant - or at least there's no contrary evidence! Then I come here, where there are plenty of other developers just as smart as I am, or possibly smarter, and here some of my ideas crash and burn. On the other hand, sometimes someone objects to my idea and the *objections* crash and burn. You can't expect to win them all when you're dealing with people who are as smart as you and more knowledgeable about the code. I try to be gentle with newcomers but it's not always easy to figure out what that means. When someone submits a bad patch and I review it, they sometimes get two or three pages of feedback detailing inadequacies of various types. I understand that can be hard on the ego, but I don't think it does anyone any favors to give them a PARTIAL list of things they need to fix - in fact I think breaking up the pain into multiple rounds is quite a bit worse, because then you create the illusion of progress without the actuality. I don't give people feedback because I want to hurt them or cause them pain, but I know from experience that until those things are fixed, it *will* *not* *get* *committed*. If I say nothing now, someone else will say it later. I am afraid that the difference between bikeshedding and legitimate criticism is something that contributors have to learn for themselves. I can tell you which things *I* think are bikeshedding, but someone else may have a longer, shorter, or same-size non-overlapping list. No one can speak with authority on this topic because no one is the boss. All that having been said, I feel your pain. I don't want to scare off new contributors, but I don't necessarily know how to improve the situation. > Probably, the only possible solution is for each new contributor to have > a mentor who sticks with them throughout the process of getting their > first contribution accepted, explaining the process, pre-reviewing their > submissions, and explaining to them which criticism they should be > paying attention to and which they shouldn't. I *thought* that Bruce > was doing that for AsterData, but apparently not. Well, this is a good idea, although I'm not sure how well it will play out in practice. I'm always game if anyone wants to email me off-list to discuss issues of this type, or... > This would require a pool of experienced contributors volunteering to be > mentors, which I'm not sure we have. ...I'm willing to do this. > It would also help if people on this list *in general*, were to be a bit > more consistent about phrasing criticism as constructive criticism. > I've seen far too much "how stupid are you?" on this list for the good > health of our developer community. I don't see very much of this at all, so maybe this is another area where it boils down to perspective. I find this list to be quite civilized most of the time; I wouldn't hang around if I didn't. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] next CommitFest
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 submit, because some people will > review extras, and some non-patch-authors will review. If they review > one patch each, that's probably more than enough. It's also easier > for bookkeeping purposes. 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 review is to read the relevant mailing list threads and try to tie up loose ends and find a consensus. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] array_to_string bug?
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 elements be >> represented as "" to differentiate ,"", (empty-string element) from ,, (null >> element). > That would cause a substantial amount of grief to people who might not > want that behavior, though. I use these functions for creating > human-readable output, not for serialization. Simple, predictable > behavior is very important. I agree --- we don't want to start introducing quoting rules into array_to_string. I think the viable alternatives are the current behavior, or treating a NULL element as if it were an empty string. David's idea that the entire output should go to NULL might be sane from a strict semantics point of view, but it also seems to make the function just about entirely useless in practice. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] array_to_string bug?
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 other contexts or > > require that empty-string elements be represented as "" to > > differentiate ,"", (empty-string element) from ,, (null element). > > That would cause a substantial amount of grief to people who might > not want that behavior, though. I use these functions for creating > human-readable output, not for serialization. Simple, predictable > behavior is very important. My question boils down to, "why is this string concatenation different from all other string concatenations?" For now, the answer can be, "it behaves differently with respect to NULLs," and we just document this. We can later decide whether this behavior should change. Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] plpgsql GUC variable: custom or built-in?
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 USER SET or ALTER DATABASE SET to modify it. However, a superuser can do that on his behalf, and then the variable will default in the desired way for that user or database. But this logic doesn't work for custom variables: the system doesn't record whether the option was set by a superuser or not, so it's afraid to allow the value to be applied when the defining module gets loaded. (Instead you get a WARNING and the value reverts to default.) I think we discussed this once before and came up with the idea that it wouldn't be a problem if ALTER USER/DATABASE SET disallowed setting of variables not currently known to the system. Right now, if plpgsql is in custom_variable_classes, you can do ALTER USER foouser SET plpgsql.variable_conflict = variable_first; and the system will take it even if plpgsql isn't loaded. If we required plpgsql to be loaded then we could be sure that the appropriate permissions check had been made when the ALTER was done, and then in subsequent sessions it would be safe to apply the variable value while loading plpgsql. One possible objection is that a loadable module couldn't safely upgrade a USERSET variable to SUSET (except across a major version boundary), since the permissions check would already have been made implicitly for any ALTER settings. This doesn't seem like a big problem compared to the current situation of not being able to use SUSET effectively at all, though. Another issue is that pg_dumpall output would fail to reload with such a restriction, since the dump script would most likely be executed in a session that hadn't loaded the relevant loadable module. We could get around that by still allowing superusers to issue ALTER SET for unknown variables, but that seems a tad weird. OTOH the current rule (must be in custom_variable_classes) is pretty hazardous for dump reloading, too. Comments? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] next CommitFest
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 sufficient review to be allowed to develop again. > >> > >> Is it really impolite for a first-contributor, no? > > > > I don't think so, as long as it's properly explained. > > Personally, I would not propose to impose this rule of first-time > contributors, or even second-time contributors. But by about patch #3 > I think everyone should be pitching in. +1. It's OK to not review anything if you're just doing a one-off. If you submit a bunch of patches you start becoming part of the community. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] next CommitFest
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 believe the community has always given extra help to first-time contributors. If anyone sees a new contributor being ignored, they should make an effort to help. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Listen / Notify rewrite
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 busted and should be reworked until it's > right. After some reflection, I realized this was an overly strong statement and impolite to the OP. It's easy to yarp from the gallery with the other peanuts :-). It's not the implementation I have an issue with, just the _idea_ that we should be restricted to small payloads for religious reasons...until that came upI was already scheming on how to both extend the patch to be more flexible in terms of payload size, and to backpatch and test it on 8.4 (no point if the community has no interest however). In any event, sorry for the strong words. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] next CommitFest
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 think we would certainly need to make an exception for first-time contributors. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] array_to_string bug?
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 as "" to differentiate ,"", (empty-string element) from ,, (null > element). That would cause a substantial amount of grief to people who might not want that behavior, though. I use these functions for creating human-readable output, not for serialization. Simple, predictable behavior is very important. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] next CommitFest
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? > I don't think so, as long as it's properly explained. -- Albert Cervera i Areny http://www.NaN-tic.com Mòbil: +34 669 40 40 18 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] next CommitFest
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 develop again. >> >> Is it really impolite for a first-contributor, no? >> > > I don't think so, as long as it's properly explained. Personally, I would not propose to impose this rule of first-time contributors, or even second-time contributors. But by about patch #3 I think everyone should be pitching in. Just MHO, of course. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] next CommitFest
> 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 authors were not doing reviews often got reviewed last, which means that sometimes they waited a commitfest. Of course, Simon submitted so many patches that despite him doing reviews, it was hard to get them all assigned. Simon: slow down a little! ;-) --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] array_to_string bug?
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 February-April regarding string_to_array with empty input which faded away somewhere around here: http://archives.postgresql.org/pgsql-hackers/2009-04/msg00363.php. At the time the decision was to defer any decision to after 8.4. Perhaps there is a solution which can address both cases - ideally one which would, to the extent practical, allow string_to_array to be the inverse of array_to_string. This could be particularly useful when dealing with clients that don't know how to directly deal with PostgreSQL arrays but which can generally easily deal with strings. 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 as "" to differentiate ,"", (empty-string element) from ,, (null element). Cheers, Steve
