Re: [HACKERS] Patch review
On Wed, 13 Feb 2008, Gregory Stark wrote: "Bruce Momjian" <[EMAIL PROTECTED]> writes: If I link to a comment URL, how do people know if they should look at that comment or all comments below it? They should look at whatever they want to. I usually have to back up several messages to understand the context and then follow several messages later. If you look at how the archives store things, the threading in there sometimes isn't sufficient to support this. As an example, I was just trying to read all the messages in the "Group Commit" thread that Bruce has tracked on "Patches Held For PostgreSQL 8.4", and for reasons I can't figure out it's split into two threads in the archives. If you just caught the earlier thread in there it would not be obvious that there's a later one. My e-mail archive, like Bruce's that he converts onto the web page, doesn't have that problem, but people not there for the original discussion wouldn't have that available. I think your basic argument that "patches queue" and "relevant discussion archive" can be managed independantly still holds, but there is some value to the way Bruce collects up the more interesting posts in the thread. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Patch review
Greg Smith wrote: > If you look at how the archives store things, the threading in there > sometimes isn't sufficient to support this. As an example, I was just > trying to read all the messages in the "Group Commit" thread that Bruce > has tracked on "Patches Held For PostgreSQL 8.4", and for reasons I can't > figure out it's split into two threads in the archives. Perhaps it's because it was split in two by a monthly boundary? (I didn't look.) -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Patch review
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Greg Smith wrote: >> If you look at how the archives store things, the threading in there >> sometimes isn't sufficient to support this. As an example, I was just >> trying to read all the messages in the "Group Commit" thread that Bruce >> has tracked on "Patches Held For PostgreSQL 8.4", and for reasons I can't >> figure out it's split into two threads in the archives. > Perhaps it's because it was split in two by a monthly boundary? (I > didn't look.) Most likely. Somebody on the www team really ought to make an effort to fix that sometime --- it reduces the value of the archives noticeably if you can't rely on the thread links. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgsql-www] [HACKERS] Patch review
On Feb 13, 2008 3:27 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > > Perhaps it's because it was split in two by a monthly boundary? (I > > didn't look.) > > Most likely. Somebody on the www team really ought to make an effort > to fix that sometime --- it reduces the value of the archives noticeably > if you can't rely on the thread links. The current system makes that pretty much unfixable. I have spent time on a PG backed replacement which does solve that and other problems but unfortunately I just haven't had time for it in a few months. If someone with PHP skillz wants to pick it up please let me know. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Oracle-compatible database company ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Patch review
On Wed, 13 Feb 2008, Alvaro Herrera wrote: Perhaps it's because it was split in two by a monthly boundary? (I didn't look.) That looks to be it. There's also another split it did manage to catch where the original author started a new thread themselves that got linked in. That sort of thing (renamed or improperly continued thread on the same topic) is another spot where someone keeping track of things manually can end up with a more consistant view of the discussion than the archives provide. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Patch review
Gregory Stark wrote: > Pointing to mail messages doesn't help us with any of that. We have to go back > and read the original message and make a judgement ourselves what state it's > in. If our judgement disagrees with others patches will just sit there with > everyone assuming someone else is looking at it. Agreed. We need that sort of info stored outside the mail list discussion itself. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Patch review
"Greg Smith" <[EMAIL PROTECTED]> writes: > On Wed, 13 Feb 2008, Alvaro Herrera wrote: > >> Perhaps it's because it was split in two by a monthly boundary? (I >> didn't look.) > > That looks to be it. There's also another split it did manage to catch where > the original author started a new thread themselves that got linked in. That > sort of thing (renamed or improperly continued thread on the same topic) is > another spot where someone keeping track of things manually can end up with a > more consistant view of the discussion than the archives provide. There's no reason we can't include links to messages from the patch queue, but the links are not sufficient in themselves to be considered the actual patch queue. The point of shared resources like a patch queue is to get us all on the same page about the status of a patch and remind us which ones are in our domain, whether we're a developer, reviewer, or committer. Pointing to mail messages doesn't help us with any of that. We have to go back and read the original message and make a judgement ourselves what state it's in. If our judgement disagrees with others patches will just sit there with everyone assuming someone else is looking at it. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Stamping of 8.4
Tom did most of the 8.4 stamping and I incremented the library minor version numbers. I have updated the library bump wording in RELEASE_CHANGES: o Bump minor library versions, major if appropriate (see below) I also updated this item description: o update config.guess and config.sub at the start of beta I see this was done already by Peter during beta: date: 2007/11/15 20:21:04; author: petere; state: Exp; lines: +25 -9 Update config.guess and config.sub so I removed the "at the start of beta" from above. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Stamping of 8.4
Sorry, please ignore me. I got "start of beta" confused with "start of development". --- Bruce Momjian wrote: > Tom did most of the 8.4 stamping and I incremented the library minor > version numbers. I have updated the library bump wording in > RELEASE_CHANGES: > > o Bump minor library versions, major if appropriate (see below) > > I also updated this item description: > > o update config.guess and config.sub at the start of beta > > I see this was done already by Peter during beta: > > date: 2007/11/15 20:21:04; author: petere; state: Exp; lines: +25 -9 > Update config.guess and config.sub > > so I removed the "at the start of beta" from above. > > -- > Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us > EnterpriseDB http://postgres.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > > ---(end of broadcast)--- > TIP 4: Have you searched our list archives? > >http://archives.postgresql.org -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Stamping of 8.4
Stephen Frost <[EMAIL PROTECTED]> writes: > * Tom Lane ([EMAIL PROTECTED]) wrote: >> Minor version bump is done unconditionally for each release cycle. > This isn't a *huge* deal, but I'm not sure it's actually appropriate. > We should bump the minor version when we actually add something new to > the library (which is probably just about every time we do a major > version, but still). Only if there were exactly zero changes would the minor version bump be unnecessary. I doubt that's ever happened. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Stamping of 8.4
Alvaro Herrera wrote: > Bruce Momjian wrote: > > Tom did most of the 8.4 stamping and I incremented the library minor > > version numbers. I have updated the library bump wording in > > RELEASE_CHANGES: > > > > o Bump minor library versions, major if appropriate (see below) > > I admit I am surprised by the library bump. We haven't done anything to > the libraries yet, so why bump the versions? It is standard practice because we always modify the library in some way, and if we don't do the minor version libraries will not favor the new version. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Stamping of 8.4
Bruce Momjian wrote: > Tom did most of the 8.4 stamping and I incremented the library minor > version numbers. I have updated the library bump wording in > RELEASE_CHANGES: > > o Bump minor library versions, major if appropriate (see below) I admit I am surprised by the library bump. We haven't done anything to the libraries yet, so why bump the versions? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Stamping of 8.4
Alvaro Herrera <[EMAIL PROTECTED]> writes: > I admit I am surprised by the library bump. We haven't done anything to > the libraries yet, so why bump the versions? Minor version bump is done unconditionally for each release cycle. Major version bump is as-needed (ABI break). regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Stamping of 8.4
Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > I admit I am surprised by the library bump. We haven't done anything to > > the libraries yet, so why bump the versions? > > Minor version bump is done unconditionally for each release cycle. Oh, I see. I will update RELEASE_CHANGES to that effect. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Stamping of 8.4
Alvaro Herrera wrote: > Tom Lane wrote: > > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > > I admit I am surprised by the library bump. We haven't done anything to > > > the libraries yet, so why bump the versions? > > > > Minor version bump is done unconditionally for each release cycle. > > Oh, I see. I will update RELEASE_CHANGES to that effect. I think I did that. Does it need more? -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Stamping of 8.4
* Tom Lane ([EMAIL PROTECTED]) wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > I admit I am surprised by the library bump. We haven't done anything to > > the libraries yet, so why bump the versions? > > Minor version bump is done unconditionally for each release cycle. This isn't a *huge* deal, but I'm not sure it's actually appropriate. We should bump the minor version when we actually add something new to the library (which is probably just about every time we do a major version, but still). Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Stamping of 8.4
Stephen Frost wrote: -- Start of PGP signed section. > * Tom Lane ([EMAIL PROTECTED]) wrote: > > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > > I admit I am surprised by the library bump. We haven't done anything to > > > the libraries yet, so why bump the versions? > > > > Minor version bump is done unconditionally for each release cycle. > > This isn't a *huge* deal, but I'm not sure it's actually appropriate. > We should bump the minor version when we actually add something new to > the library (which is probably just about every time we do a major > version, but still). The problem is the risk of forgetting during development. When we break an API it is obvious, but improvements are so regular you can't remember when you first do it for each interface. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Stamping of 8.4
Bruce Momjian <[EMAIL PROTECTED]> writes: > Stephen Frost wrote: >> We should bump the minor version when we actually add something new to >> the library (which is probably just about every time we do a major >> version, but still). > The problem is the risk of forgetting during development. When we break > an API it is obvious, but improvements are so regular you can't remember > when you first do it for each interface. We could possibly do the bump at the end of the cycle (eg, just before beta) if no major bump has happened meanwhile. However, this would complicate life for developers. I believe one of the arguments for the immediate minor bump was so that you could tell a development library from the previous release version, and (if your platform lets you) even install them in parallel. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Stamping of 8.4
Bruce Momjian wrote: > Alvaro Herrera wrote: > > Tom Lane wrote: > > > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > > > I admit I am surprised by the library bump. We haven't done anything to > > > > the libraries yet, so why bump the versions? > > > > > > Minor version bump is done unconditionally for each release cycle. > > > > Oh, I see. I will update RELEASE_CHANGES to that effect. > > I think I did that. Does it need more? Yeah, you didn't touch the "Minor Version" subsection of "Library Version Changes". -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Stamping of 8.4
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Stephen Frost wrote: > >> We should bump the minor version when we actually add something new to > >> the library (which is probably just about every time we do a major > >> version, but still). > > > The problem is the risk of forgetting during development. When we break > > an API it is obvious, but improvements are so regular you can't remember > > when you first do it for each interface. > > We could possibly do the bump at the end of the cycle (eg, just before > beta) if no major bump has happened meanwhile. However, this would > complicate life for developers. I believe one of the arguments for the > immediate minor bump was so that you could tell a development library > from the previous release version, and (if your platform lets you) even > install them in parallel. Yes, a late bump would invalidate a lot of installations running CVS in testing. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] NLS on MSVC strikes back!
Hi. Still, my health is not good... First, Probably, as for the 8.3 release binary, NLS is offed. Even if it arranges shar/locale, it is not used. Next, NLS was confirmed by VCBUILD of CVS-HEAD. A very interesting result can be seen here. http://inet.winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/ It was expressed by LC_MESSAGE=C. Anyway, in Japan, it is hard to use.. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] wishlist for 8.4
hi there, I recently found myself trying to build a trigger to modify some fields in a good dozen similarly structured tables in which the similar columns had different names. in fact, I got stuck in pl/pgsql with the fact that there's no way to access the NEW tuple in an indirect way, having the name of the column in some variable. (I found that it could be done in plperl, but that left me with a taste of un-completeness...) so, I propose the use of NEW[variable_containing_the_column_name] (which can obviously be extended to any tuples) to allow such access. what do you experts think ? ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] Timezone view
I brought this up a while ago, but I didn't get any responses, I assume due to everyone being too busy with 8.3 I think that it would be great if the pg_timezone_names and pg_timezone_abbrevs included a boolean field indicating if that item is in the Olsen DB or if it is a system alias or other added item. This would make it far easier to integrate the data in the view with external data sources that also use the Olsen DB. It may also be beneficial to add the ISO 3166 column into that view, the data is in zone.tab and I can't see a reason to not include it. - Naz. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Patch review
Alvaro Herrera wrote: > Gregory Stark wrote: > > > Pointing to mail messages doesn't help us with any of that. We have to go > > back > > and read the original message and make a judgement ourselves what state it's > > in. If our judgement disagrees with others patches will just sit there with > > everyone assuming someone else is looking at it. > > Agreed. We need that sort of info stored outside the mail list > discussion itself. Now that we have comments on the patch queue people can actually claim items. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] Show INHERIT in \du
Hello hackers, psql's \du command currently does not list the INHERIT role attribute. It does show the other privilege attributes (superuser, create role, create db), and INHERIT seems like the kind of thing a user executing\du would want to know. I'd like to add it to \du. The downside is that it would add width to an already rather wide output, but I see that as a worthwhile tradeoff. If I'm in the minority there, perhaps I could just add it to \du+? TIA for your comments. Cheers, BJ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
