Re: [HACKERS] Release Note Changes
On Sat, 2007-12-08 at 12:46 -0500, Bruce Momjian wrote: > Alvaro Herrera wrote: > > Simon's the guy who (rightfully, IMHO) smacked me for forgetting to > > credit him on a commit message. Credit is important to some people. > > Let's not get in the business of annoying the people who gives their > > work for free. For some, credit is the second sole reason for hacking > > Postgres (first one being because it's fun). If I had had no credit, > > I wouldn't have a job. > > > > If anyone explicitly says that credit is not important to him, feel > > free to remove his name from the release notes. I doubt you're going to > > get many takers. > > I don't think people are going to volunteer to remove just their name > but they might agree to remove them all. I'm not sure how a thread about a few missing items on the performance list became a discussion about removing all credits. The release notes are there to inform people about important features, so if me waiving any credit on those missing items is what is required to get them mentioned, I will happily do so. Please add the items I mentioned upthread. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Release Note Changes
On Sat, 2007-12-08 at 10:13 -0300, Alvaro Herrera wrote: > If I had had no credit, I wouldn't have a job. Agree with this 100% I don't have a problem with mentioning sponsoring companies on the bottom of the release notes. I think it will encourage wider sponsorship if people do that. Probably should be optional though, allowing sponsors that want to remain anonymous to do so. "Simon Riggs was primarily sponsored by EnterpriseDB, with additional sponsorship from 2ndQuadrant during the 8.3 release cycle." or something similar. I'm very thankful to Denis Lussier in particular for allowing me a clear schedule right up to the 8.3 feature freeze, without which many items would not have been completed. (I'd also like to thank Greenplum for their partial sponsorship of my work for the 8.1 and 8.2 releases). Encouraging sponsorship is good; nobody loses from it, since everybody gains from the software that gets written. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Possible PostgreSQL 8.3beta4 bug with MD5 authentication in psql?
On Sat, 2007-12-08 at 17:09 -0500, Tom Lane wrote: > So what I think we must do is split the function into two: > > PQconnectionNeedsPassword: true if server demanded a password and there > was none to send (hence, can only be true for a failed connection) > > PQconnectionUsedPassword: true if server demanded a password and it > was supplied from the connection function's argument list, *not* > from environment or a password file. > > Offhand it looks like only dblink needs the second version --- > all of our client-side code wants the first one. > > Barring objections I'll go code this up ... Yup, that looks good to me. My only criticism would be that the name PQconnectionUsedPassword could be a little misleading, in that based upon the name I would expect it to return true if a password was specified regardless of whether the method used was interactive, .pgpass or PGPASSWORD. The only other suggestion I can think of at the moment would be PQconnectionUsedConnectionPassword which seems to better sum up its purpose to me... Kind regards, Mark. -- ILande - Open Source Consultancy http://www.ilande.co.uk ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] PGparam timestamp question
I am trying to add support for timestamps in our proposed libpq PGparam patch. I ran into something I don't really understand. I wasn't sure if it was my libpq code that was wrong (converts a binary timestamp into a time_t or struct tm) so I tried it from psql. Server is using EST (8.3devel) x86_64 centos 5 TIMESTAMP WITHOUT TIME ZONE appears to be incorrectly adjusting the time. postgres=# create table t (ts timestamp); postgres=# insert into t values (now()); postgres=# select * from t; ts 2007-12-09 08:00:00.056244 postgres=# select ts at time zone 'UTC' from t; timezone --- 2007-12-09 03:00:00.056244-05 > Shouldn't this be 13:00 TIMESTAMP WITH TIME ZONE returns the result I would expect. postgres=# create table t (ts timestamp with time zone); postgres=# insert into t values (now()); postgres=# select * from t; ts 2007-12-09 08:00:00.056244 postgres=# select ts at time zone 'UTC' from t; timezone --- 2007-12-09 13:00:00.056244-05 Is this expected/desired behavior? If it is, how are timestamps stored internally for WITHOUT TIME ZONE types? The docs don't really say. They do discuss how WITH TIME ZONE stores things, but WITHOUT is a little blury. Maybe I am missing something simple. Andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Release Note Changes
Simon Riggs wrote: > On Sat, 2007-12-08 at 10:13 -0300, Alvaro Herrera wrote: > > If I had had no credit, I wouldn't have a job. > > Agree with this 100% > > > > I don't have a problem with mentioning sponsoring companies on the > bottom of the release notes. I think it will encourage wider sponsorship > if people do that. Probably should be optional though, allowing sponsors > that want to remain anonymous to do so. > > "Simon Riggs was primarily sponsored by EnterpriseDB, with additional > sponsorship from 2ndQuadrant during the 8.3 release cycle." or something > similar. I'm very thankful to Denis Lussier in particular for allowing > me a clear schedule right up to the 8.3 feature freeze, without which > many items would not have been completed. (I'd also like to thank > Greenplum for their partial sponsorship of my work for the 8.1 and 8.2 > releases). > > Encouraging sponsorship is good; nobody loses from it, since everybody > gains from the software that gets written. The release notes are not the place for sponsor advertizement. And removing the names was so we could be fair and mention on one, not to allow additional items to be added to the list. -- 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] Release Note Changes
Joshua D. Drake wrote: > > > I am actually a little worried that companies who sponsor developers > > might some day want their company name on the release note item. I am > > glad we have not had to make that decision yet. This actually > > O.k. I will bite :) > > > > highlights a danger of having "giving credit" be a more major part of > > the release notes in that companies could ask that they the company be > > given credit in the release notes --- something we want to avoid. > > Why? If a company sponsored the feature why not mention them? > > > Note that I am not arguing one way or the other, but I find the > distinction between a individual who is a contributor and a company that > is a contributor interesting. Individual mentions are only so we know who did the work. Company names are for advertizement, and that doesn't belong in the release notes. -- 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] PGparam timestamp question
On Sunday 09 December 2007 09:44, Andrew Chernow wrote:
> I am trying to add support for timestamps in our proposed libpq PGparam
> patch. I ran into something I don't really understand. I wasn't sure if it
> was my libpq code that was wrong (converts a binary timestamp into a time_t
> or struct tm) so I tried it from psql.
>
> Server is using EST (8.3devel) x86_64 centos 5
>
> TIMESTAMP WITHOUT TIME ZONE appears to be incorrectly adjusting the time.
>
> postgres=# create table t (ts timestamp);
> postgres=# insert into t values (now());
> postgres=# select * from t;
> ts
>
> 2007-12-09 08:00:00.056244
>
> postgres=# select ts at time zone 'UTC' from t;
> timezone
> ---
> 2007-12-09 03:00:00.056244-05 > Shouldn't this be 13:00
>
No. 8 AM UTC is 3 AM Eastern.
>
> TIMESTAMP WITH TIME ZONE returns the result I would expect.
>
> postgres=# create table t (ts timestamp with time zone);
> postgres=# insert into t values (now());
> postgres=# select * from t;
> ts
>
> 2007-12-09 08:00:00.056244
>
> postgres=# select ts at time zone 'UTC' from t;
> timezone
> ---
> 2007-12-09 13:00:00.056244-05
>
Correspondingly, 8 AM eastern is 1 PM UTC.
>
> Is this expected/desired behavior? If it is, how are timestamps stored
> internally for WITHOUT TIME ZONE types? The docs don't really say. They
> do discuss how WITH TIME ZONE stores things, but WITHOUT is a little blury.
> Maybe I am missing something simple.
>
When timestamptzs are converted to timestamp, there is no time adjust, you
simply lose the tz offset information:
pagila=# select now(), now()::timestamp;
-[ RECORD 1 ]--
now | 2007-12-09 11:25:52.923612-05
now | 2007-12-09 11:25:52.923612
If you store without timezone, you lose the original timezone information, so
selecting out "with time zone" simply selects the stored time in the time
zone you selected. HTH.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
[HACKERS] whats the deal with -u ?
[EMAIL PROTECTED]:~$ ~rob/devel/postgresql/83/bin/psql -h localhost -u rob -p
5483]
psql: Warning: The -u option is deprecated. Use -U.
User name: rob
Password for user :
Welcome to psql 8.3beta2, the PostgreSQL interactive terminal.
1) I don't recall why -u was ever deprecated (and honestly postgresql is the
only program I know which uses -U rather than -u) but maybe we should revert
to -u and deprecate -U instread?
2) in any case, if you use -u for some reason it messes up the "Password for
user " line. In my terminal it gives me a square which doesnt show up in my
email, but in any case is there some reason it can't print out the proper
user name (maybe some encoding issue?)
3) as far back as I can remember, -u has been deprecated, so if we dont want
to revert to it (see 1) maybe it should just be removed entirely?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(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] PGparam timestamp question
Okay, thanks. So using WITHOUT TIME ZONE basically means, store the provided value as UTC. Meaning, 8AM EST NOW() is stored/treated as 8AM UTC. That explains why my libpq code was getting 3AM for "without time zone" values. I am using code from src/interfaces/ecpg/pgtypeslib/timestamp.c timestamp2tm(). That uses localtime() after converting the timestamp to an epoch value. I changed this code so that it calls gmtime() for TIMESTAMPOID and localtime() for TIMESTAMPTZOID. Now it works perfectly :) Need to figure out how to handle times outside of the system time_t range. Thanks again, Andrew Robert Treat wrote: On Sunday 09 December 2007 09:44, Andrew Chernow wrote: I am trying to add support for timestamps in our proposed libpq PGparam patch. I ran into something I don't really understand. I wasn't sure if it was my libpq code that was wrong (converts a binary timestamp into a time_t or struct tm) so I tried it from psql. Server is using EST (8.3devel) x86_64 centos 5 TIMESTAMP WITHOUT TIME ZONE appears to be incorrectly adjusting the time. postgres=# create table t (ts timestamp); postgres=# insert into t values (now()); postgres=# select * from t; ts 2007-12-09 08:00:00.056244 postgres=# select ts at time zone 'UTC' from t; timezone --- 2007-12-09 03:00:00.056244-05 > Shouldn't this be 13:00 No. 8 AM UTC is 3 AM Eastern. TIMESTAMP WITH TIME ZONE returns the result I would expect. postgres=# create table t (ts timestamp with time zone); postgres=# insert into t values (now()); postgres=# select * from t; ts 2007-12-09 08:00:00.056244 postgres=# select ts at time zone 'UTC' from t; timezone --- 2007-12-09 13:00:00.056244-05 Correspondingly, 8 AM eastern is 1 PM UTC. Is this expected/desired behavior? If it is, how are timestamps stored internally for WITHOUT TIME ZONE types? The docs don't really say. They do discuss how WITH TIME ZONE stores things, but WITHOUT is a little blury. Maybe I am missing something simple. When timestamptzs are converted to timestamp, there is no time adjust, you simply lose the tz offset information: pagila=# select now(), now()::timestamp; -[ RECORD 1 ]-- now | 2007-12-09 11:25:52.923612-05 now | 2007-12-09 11:25:52.923612 If you store without timezone, you lose the original timezone information, so selecting out "with time zone" simply selects the stored time in the time zone you selected. HTH. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [DOCS] Re: [HACKERS] Uniform policy for author credits in contrib module documentation?
On Thursday 06 December 2007 03:54, Magnus Hagander wrote:
> On Wed, Dec 05, 2007 at 10:46:51PM -0800, Joshua D. Drake wrote:
> > Tom Lane wrote:
> > >As of CVS HEAD, some of the contrib module documentation pages have
> > >extensive credit screeds, eg
> > >http://developer.postgresql.org/pgdocs/postgres/cube.html
> > >and some just have the author's name, with or without an link,
> > >and some don't have anything at all.
> > >
> > >I don't have a strong opinion one way or the other, except that I think
> > >we should have a uniform policy for all the contrib modules.
> >
> > Well once we push directly into the core documentation I agree that
> > outside of release notes (although you just brought that up in another
> > thread) we don't need to be mentioning contributions like that. Those
> > who have contributed are in the logs.
> >
> > Further those who have provided reasonable contribution really should be
> > mentioned on the contributors page that is up for discussion which would
> > make the rest of this moot yes?
>
> +1, since they are listed in the release notes when the contrib modules are
> added - just like any other piece of code. IMO no reason to treat contrib
> differently from any other code in this case.
>
Hmm, I have often seen that the person listed in the contrib docs was
considered the person to contact if you had questions/comments/patches/etc...
about a specific contrib module. I wonder if people would still get the same
level of help if those names are removed and they have to go to the regular
mailing lists for help (which contrib authors may not follow).
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] whats the deal with -u ?
Robert Treat wrote: [EMAIL PROTECTED]:~$ ~rob/devel/postgresql/83/bin/psql -h localhost -u rob -p 5483] psql: Warning: The -u option is deprecated. Use -U. User name: rob Password for user : Welcome to psql 8.3beta2, the PostgreSQL interactive terminal. 1) I don't recall why -u was ever deprecated (and honestly postgresql is the only program I know which uses -U rather than -u) but maybe we should revert to -u and deprecate -U instread? 2) in any case, if you use -u for some reason it messes up the "Password for user " line. In my terminal it gives me a square which doesnt show up in my email, but in any case is there some reason it can't print out the proper user name (maybe some encoding issue?) 3) as far back as I can remember, -u has been deprecated, so if we dont want to revert to it (see 1) maybe it should just be removed entirely? As I recall -u actually used a different mechanism to authenticate versus -U. In fact I think it was a security hole that changed it but it was a LONG time ago. I would agree that one or the other needs to be removed. Unfortunately -U has been the way it is for several releases now so I can't see us going back to -u regardless of how logical it may be. Joshua D. Drake ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PGparam timestamp question
On Sunday 09 December 2007 11:54, Andrew Chernow wrote:
> Okay, thanks. So using WITHOUT TIME ZONE basically means, store the
> provided value as UTC. Meaning, 8AM EST NOW() is stored/treated as 8AM
> UTC.
>
Not quite. Using WITHOUT TIME ZONE means to not store any time zone
information. It appears as UTC only because you selected it out as UTC.
pagila=# select now(), now() at time zone 'PST' , now()::timestamp at time
zone 'PST';
-[ RECORD 1 ]---
now | 2007-12-09 12:25:19.240661-05
timezone | 2007-12-09 09:25:19.240661
timezone | 2007-12-09 15:25:19.240661-05
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(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] PGparam timestamp question
Andrew Chernow <[EMAIL PROTECTED]> writes: > Okay, thanks. So using WITHOUT TIME ZONE basically means, store the provided > value as UTC. Meaning, 8AM EST NOW() is stored/treated as 8AM UTC. No, I think you are more confused now than you were before. For both types, the underlying stored value is just a number-of-seconds offset from 2000-01-01 00:00:00. The question is what's the reference time really. For WITHOUT TIME ZONE, what you see is what you get: it's just a date and time, and nobody is actually promising anything about timezone considerations. For WITH TIME ZONE, the convention is that the reference time is 2000-01-01 00:00:00 UTC, and therefore it is accurate to say that the *stored value* is always expressed in UTC. What confuses people is that for display purposes, a TIMESTAMP WITH TIME ZONE value is rotated to your local timezone (as set by the timezone variable) and printed with your local zone offset. But that's not what's really stored. Now, about AT TIME ZONE: that's a trickier operation than it looks. When you start with a timestamp WITH time zone, the meaning is "here's a UTC time, give me the equivalent local time in this time zone". What comes out is a timestamp WITHOUT time zone, which means it'll just be printed as-is. When you start with a timestamp WITHOUT time zone, the meaning is "here is a local time in this time zone, give me the equivalent UTC time". What comes out is a timestamp WITH time zone, which as we already saw is implicitly UTC inside the system, which is correct. But you have to remember that that value will be rotated back to your local zone for display. I think that extra conversion is what was confusing you to start with. Another point to keep in mind is that if the system is forced to assume something about the timezone of a WITHOUT TIME ZONE value, it will assume your local time zone setting. In particular this happens during forced coercions between WITH and WITHOUT TIME ZONE. So for example, in regression=# select now(), now()::timestamp without time zone; now |now ---+ 2007-12-09 13:21:50.619644-05 | 2007-12-09 13:21:50.619644 (1 row) the two values are in fact different numbers-of-seconds internally. They print the same, but that's because in the first case the timestamp-with-time-zone output routine rotated from UTC to my local zone (EST) during printout. In the second case the same 5-hour offset was applied by the cast to without-time-zone, and then the timestamp-without-time-zone output routine just printed what it had without any magic. 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] whats the deal with -u ?
Robert Treat <[EMAIL PROTECTED]> writes: > 1) I don't recall why -u was ever deprecated (and honestly postgresql is the > only program I know which uses -U rather than -u) but maybe we should revert > to -u and deprecate -U instread? You appear to think that -u and -U are supposed to be equivalent. You are incorrect. -u forces prompts for username and password. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] whats the deal with -u ?
On Sunday 09 December 2007 13:33, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > 1) I don't recall why -u was ever deprecated (and honestly postgresql is
> > the only program I know which uses -U rather than -u) but maybe we should
> > revert to -u and deprecate -U instread?
>
> You appear to think that -u and -U are supposed to be equivalent.
> You are incorrect. -u forces prompts for username and password.
>
Ah, you're right, I didn't realize that (probably because nothing in the
warnings seem to indicate that). However I think all of my questions still
remain valid, if not becoming even further re-encforced:
[EMAIL PROTECTED]:~$ ~rob/devel/postgresql/83/bin/psql -h localhost -u -p 5483
psql: Warning: The -u option is deprecated. Use -U.
If I wanted to prompt for a username, why is it telling me to use -U? If
we've deemed that's not a valid behavior to want, see questions 1,2 & 3 from
upthread :-)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [HACKERS] whats the deal with -u ?
I don't remember why it's deprecated. These days it seems to use the same prompting mechanism as we use for passwords, so hopefully there is no security risk. Maybe it should be un-deprecated? I'd tend to take out the forced password prompt if we did, though. 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] whats the deal with -u ?
I wrote: > I don't remember why it's deprecated. Some trawling of the CVS logs shows that the deprecation notice was added by Peter here: 2000-01-14 17:18 petere * doc/src/sgml/ref/psql-ref.sgml, src/bin/psql/command.c, src/bin/psql/command.h, src/bin/psql/common.c, src/bin/psql/common.h, src/bin/psql/copy.c, src/bin/psql/copy.h, src/bin/psql/describe.c, src/bin/psql/describe.h, src/bin/psql/help.c, src/bin/psql/help.h, src/bin/psql/input.c, src/bin/psql/input.h, src/bin/psql/large_obj.c, src/bin/psql/large_obj.h, src/bin/psql/mainloop.c, src/bin/psql/mainloop.h, src/bin/psql/prompt.c, src/bin/psql/prompt.h, src/bin/psql/settings.h, src/bin/psql/startup.c: Fixed psql variables vs array syntax, as well as minor psql enhancements but I failed to find any discussion about the reason in the archives. Peter? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] buildenv.pl/buildenv.bat
Magnus Hagander wrote:
You seem to have misunderstood what I am suggesting. Of course we should
document use of buildenv.pl in addition to the hacky fix to the .bat
files. The hack is the part that would be invisible. The docs would be
visible and contain what would be our ongoing practice.
Correct, I was misunderstanding it :-)
I still can't say I like that hack though. I'd rather document that you
have to do it in the .bat file for docs + gui build.
But it's better than what I thought you were proposing :-)
Well, I honestly think we can live with it for one cycle. As soon as 8.4
opens I'll get to work converting these .bat files to pure one line
wrappers.
Meanwhile, here's the proposed patch. If you want something else you'll
have to do it.
I don't know how many people regularly build on Windows other than you,
me and Dave.
cheers
andrew
Index: doc/src/sgml/install-win32.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/install-win32.sgml,v
retrieving revision 1.42
diff -c -r1.42 install-win32.sgml
*** doc/src/sgml/install-win32.sgml 28 Nov 2007 15:42:31 - 1.42
--- doc/src/sgml/install-win32.sgml 9 Dec 2007 19:31:36 -
***
*** 58,69
Before you build, edit the file config.pl to reflect the
configuration options you want set, including the paths to libraries used.
If you need to set any other environment variables, create a file called
! buildenv.bat and put the required commands there. For
example, to add the path for bison when it's not in the PATH, create a file
containing:
!@ECHO OFF
!SET PATH=%PATH%;c:\some\where\bison\bin
--- 58,68
Before you build, edit the file config.pl to reflect the
configuration options you want set, including the paths to libraries used.
If you need to set any other environment variables, create a file called
! buildenv.pl and put the required commands there. For
example, to add the path for bison when it's not in the PATH, create a file
containing:
!$ENV{PATH}=$ENV{PATH} . ';c:\some\where\bison\bin';
***
*** 209,218
To change the default build configuration to debug, put the following
!in the buildenv.bat file:
! set CONFIG=Debug
--- 208,217
To change the default build configuration to debug, put the following
!in the buildenv.pl file:
! $ENV{CONFIG}="Debug";
***
*** 263,269
required parts first. Also, make sure that the DLLs required to load all
parts of the system (such as the Perl and Python DLLs for the procedural
languages) are present in the system path. If they are not, set it through
!the buildenv.bat file. To run the tests, run one of
the following commands from the src\tools\msvc
directory:
--- 262,268
required parts first. Also, make sure that the DLLs required to load all
parts of the system (such as the Perl and Python DLLs for the procedural
languages) are present in the system path. If they are not, set it through
!the buildenv.pl file. To run the tests, run one of
the following commands from the src\tools\msvc
directory:
***
*** 339,349
!Edit the buildenv.bat file, and add a variable for the
location of the root directory, for example:
! @ECHO OFF
! SET DOCROOT=c:\docbook
To build the documentation, run the command
builddoc.bat. Note that this will actually run the
--- 338,347
!Edit the buildenv.pl file, and add a variable for the
location of the root directory, for example:
! $ENV{DOCROOT}='c:\docbook';
To build the documentation, run the command
builddoc.bat. Note that this will actually run the
Index: src/tools/msvc/builddoc.bat
===
RCS file: /cvsroot/pgsql/src/tools/msvc/builddoc.bat,v
retrieving revision 1.5
diff -c -r1.5 builddoc.bat
*** src/tools/msvc/builddoc.bat 17 Mar 2007 14:01:01 - 1.5
--- src/tools/msvc/builddoc.bat 9 Dec 2007 19:31:36 -
***
*** 1,5
@echo off
! REM Adjust path for your docbook installation in buildenv.bat
REM $PostgreSQL: pgsql/src/tools/msvc/builddoc.bat,v 1.5 2007/03/17 14:01:01 mha Exp $
--- 1,5
@echo off
! REM Adjust path for your docbook installation in buildenv.pl
REM $PostgreSQL: pgsql/src/tools/msvc/builddoc.bat,v 1.5 2007/03/17 14:01:01 mha Exp $
***
*** 10,16
IF EXIST ..\msvc IF EXIST ..\..\..\src cd ..\..\..
IF NOT EXIST doc\src\sgml\version.sgml goto noversion
! IF EXIST src\tools\msvc\buildenv.bat CALL src\tools\msvc\buildenv.bat
IF NOT EXIST %DOCROOT%\%OPENJADE% SET NF=OpenJade
IF NOT EXIST %DOCROOT%\
Re: [HACKERS] Release Note Changes
Alvaro Herrera wrote: > Yeah, I don't know when did that start but I would prefer that the names > would be spelled in full. On the other hand, having a first name only > is a kind of a sign that you're already an established developer. Still > I would like my last name to be there and I was considering adding it > myself. The problem with full names is that right now the names are mostly from frequent contributors, and hance one word. If we go with full names the attribution becomes longer and we might decide we just want to remove names completely. When I started we were small so naming folks made sense, but now that we are larger perhaps the name detracts from the polish of the release notes and should be removed. Of course, if we do that, we have to start a new thread and discuss it. > > The bottom line is that the release notes for not for attribution, but > > we do attribute if the item appears on the release notes. This seems > > like the best balance, though it is unfair in failing to attribute work > > to many contributors. > > Yeah. In my opinion, we're not really looking for 100% fairness. I > think credit is important, so if Stefan Kaltenbrunner did some psql > autocomplete work and it's not attributed, let's add a note to that > effect. There is no point in saying exactly how many lines he > contributed, nor listing the exact changes he did, though. I do think we have demand for an "internals" section of the release notes or a separate section on 8.3 internals, but it should list all changes in 8.3 that are not in the main release notes. -- 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] Release Note Changes
Bruce Momjian wrote: > Joshua D. Drake wrote: > > > > > I am actually a little worried that companies who sponsor developers > > > might some day want their company name on the release note item. I am > > > glad we have not had to make that decision yet. This actually > > > > O.k. I will bite :) > > > > > > > highlights a danger of having "giving credit" be a more major part of > > > the release notes in that companies could ask that they the company be > > > given credit in the release notes --- something we want to avoid. > > > > Why? If a company sponsored the feature why not mention them? > > > > > > Note that I am not arguing one way or the other, but I find the > > distinction between a individual who is a contributor and a company that > > is a contributor interesting. > > Individual mentions are only so we know who did the work. Company names > are for advertisement, and that doesn't belong in the release notes. I am thinking company names for advertisement belong in the press release. -- 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 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] Release Note Changes
"Bruce Momjian" <[EMAIL PROTECTED]> writes: > Joshua D. Drake wrote: > >> Note that I am not arguing one way or the other, but I find the >> distinction between a individual who is a contributor and a company that >> is a contributor interesting. > > Individual mentions are only so we know who did the work. Company names > are for advertizement, and that doesn't belong in the release notes. I think it would be kind of neat to see all the sponsored work somewhere. Only I think it may be a bit repetitive with Redhat sponsoring most of the best stuff... :) As for what items should go in, I think it should be pretty clear if you put yourself in the seat of a user trying to determine if upgrading will solve problems with their application or allow them to do things with their application that they couldn't before. It's certainly possible for performance improvements to affect that. I think "multiple space reductions, especially (but not only) for text, numeric and other variable sized data" could easily be something which particular DBAs would have noticed was a problem they needed to deal with. I understand the thinking but I disagree that "various optimizations speeding up merge sort, reducing contention at transaction start and end, ..." is entirely content-free. I agree that nobody is really going to be specifically saying "gee, i wish we could use postgres but merge-join is just too slow". However as a user I find it helpful to get a kind of overview of the kinds of invisible changes there were so I can get a feel for the magnitude of the improvements between versions. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] PGparam timestamp question
got it. stored vs. displyed was confusing me. Andrew Tom Lane wrote: Andrew Chernow <[EMAIL PROTECTED]> writes: Okay, thanks. So using WITHOUT TIME ZONE basically means, store the provided value as UTC. Meaning, 8AM EST NOW() is stored/treated as 8AM UTC. No, I think you are more confused now than you were before. For both types, the underlying stored value is just a number-of-seconds offset from 2000-01-01 00:00:00. The question is what's the reference time really. For WITHOUT TIME ZONE, what you see is what you get: it's just a date and time, and nobody is actually promising anything about timezone considerations. For WITH TIME ZONE, the convention is that the reference time is 2000-01-01 00:00:00 UTC, and therefore it is accurate to say that the *stored value* is always expressed in UTC. What confuses people is that for display purposes, a TIMESTAMP WITH TIME ZONE value is rotated to your local timezone (as set by the timezone variable) and printed with your local zone offset. But that's not what's really stored. Now, about AT TIME ZONE: that's a trickier operation than it looks. When you start with a timestamp WITH time zone, the meaning is "here's a UTC time, give me the equivalent local time in this time zone". What comes out is a timestamp WITHOUT time zone, which means it'll just be printed as-is. When you start with a timestamp WITHOUT time zone, the meaning is "here is a local time in this time zone, give me the equivalent UTC time". What comes out is a timestamp WITH time zone, which as we already saw is implicitly UTC inside the system, which is correct. But you have to remember that that value will be rotated back to your local zone for display. I think that extra conversion is what was confusing you to start with. Another point to keep in mind is that if the system is forced to assume something about the timezone of a WITHOUT TIME ZONE value, it will assume your local time zone setting. In particular this happens during forced coercions between WITH and WITHOUT TIME ZONE. So for example, in regression=# select now(), now()::timestamp without time zone; now |now ---+ 2007-12-09 13:21:50.619644-05 | 2007-12-09 13:21:50.619644 (1 row) the two values are in fact different numbers-of-seconds internally. They print the same, but that's because in the first case the timestamp-with-time-zone output routine rotated from UTC to my local zone (EST) during printout. In the second case the same 5-hour offset was applied by the cast to without-time-zone, and then the timestamp-without-time-zone output routine just printed what it had without any magic. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Release Note Changes
Gregory Stark wrote: "Bruce Momjian" <[EMAIL PROTECTED]> writes: Joshua D. Drake wrote: Note that I am not arguing one way or the other, but I find the distinction between a individual who is a contributor and a company that is a contributor interesting. Individual mentions are only so we know who did the work. Company names are for advertizement, and that doesn't belong in the release notes. I think it would be kind of neat to see all the sponsored work somewhere. Only I think it may be a bit repetitive with Redhat sponsoring most of the best stuff... :) Hah! It's certainly possible for performance improvements to affect that. I think "multiple space reductions, especially (but not only) for text, numeric and other variable sized data" could easily be something which particular DBAs would have noticed was a problem they needed to deal with. Well let's take it a step back because I think you are on to something here. Our customers will "directly" see a benefit from the changes Greg made for 8.3 on the space reductions. Not only is a benefit for on disk storage but it is also a direct performance benefit. When my customers say... why does 8.3 take so much less space than 8.2, I will tell them and further expound on it being one of the key components to their greater performance. Most of out customers however will not notice one of our key contributions which was the multi-worker autovacuum. Yes it is important. Yes we have specific customers that will benefit greatly from it but the mass majority will not. I understand the thinking but I disagree that "various optimizations speeding up merge sort, reducing contention at transaction start and end, ..." is entirely content-free. I agree that nobody is really going to be specifically saying "gee, i wish we could use postgres but merge-join is just too slow". Right. However as a user I find it helpful to get a kind of overview of the kinds of invisible changes there were so I can get a feel for the magnitude of the improvements between versions. I agree with this as well. However, I am starting to wonder if the "release notes" is the place for this. I am starting to think that instead we need a white paper on the release (or each release) that is categorized and reasonably in depth on "why" 8.3 (or 8.4 etc..). Sincerely, Joshua D. Drake ---(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] Release Note Changes
Gregory Stark wrote: > I understand the thinking but I disagree that "various optimizations speeding > up merge sort, reducing contention at transaction start and end, ..." is > entirely content-free. I agree that nobody is really going to be specifically > saying "gee, i wish we could use postgres but merge-join is just too slow". > However as a user I find it helpful to get a kind of overview of the kinds of > invisible changes there were so I can get a feel for the magnitude of the > improvements between versions. Agreed. You will have to convince Tom because it was mostly such items from him in previous release that he asked to be removed. -- 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] Release Note Changes
Joshua D. Drake wrote: > > However as a user I find it helpful to get a kind of overview of the kinds > > of > > invisible changes there were so I can get a feel for the magnitude of the > > improvements between versions. > > > > I agree with this as well. However, I am starting to wonder if the > "release notes" is the place for this. I am starting to think that > instead we need a white paper on the release (or each release) that is > categorized and reasonably in depth on "why" 8.3 (or 8.4 etc..). Sure, and we could perhaps put up with some gritty detail there, though it doesn't solve the problem of people's work not being mentioned. Seems that is a separate problem. -- 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] Release Note Changes
Bruce Momjian wrote: Joshua D. Drake wrote: However as a user I find it helpful to get a kind of overview of the kinds of invisible changes there were so I can get a feel for the magnitude of the improvements between versions. I agree with this as well. However, I am starting to wonder if the "release notes" is the place for this. I am starting to think that instead we need a white paper on the release (or each release) that is categorized and reasonably in depth on "why" 8.3 (or 8.4 etc..). Sure, and we could perhaps put up with some gritty detail there, though it doesn't solve the problem of people's work not being mentioned. Seems that is a separate problem. I assumed the white paper would have proper attribution. Sincerely, Joshua D. Drake ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Release Note Changes
Joshua D. Drake wrote: > Bruce Momjian wrote: > > Joshua D. Drake wrote: > >>> However as a user I find it helpful to get a kind of overview of the > >>> kinds of > >>> invisible changes there were so I can get a feel for the magnitude of the > >>> improvements between versions. > >>> > >> I agree with this as well. However, I am starting to wonder if the > >> "release notes" is the place for this. I am starting to think that > >> instead we need a white paper on the release (or each release) that is > >> categorized and reasonably in depth on "why" 8.3 (or 8.4 etc..). > > > > Sure, and we could perhaps put up with some gritty detail there, though > > it doesn't solve the problem of people's work not being mentioned. > > Seems that is a separate problem. > > I assumed the white paper would have proper attribution. Right, but is the white paper going to be thorough to mention _all_ changes? -- 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] Release Note Changes
Based on this discussion I think it is clear the release notes chapter needs an introductory section. This would not be for any specific release but the release notes in general. I have come up with the following text: The release notes contain the significant changes for each PostgreSQL release, with major features or migration issues often listed at the top. The release notes do not contain changes that affect only a few users or changes that are internal and therefore not user-visible. For example, the optimizer is improved in almost every release, but the improvements are usually observed by users as simply faster queries. A complete list of all changes for a release can only be obtained by viewing the CVS logs for each release. The committers email list (http://archives.postgresql.org/pgsql-committers/) contains all source code changes as well. There is also a web interface that shows changes to specific files or directories (http://developer.postgresql.org/cvsweb.cgi/pgsql/). (XXX SVN is good but needs "Next" button at bottom, no branch filter, https certificate update https://projects.commandprompt.com/public/pgsql/log/?action=stop_on_copy&rev=&stop_rev=&mode=stop_on_copy&verbose=on). A names appearing next to an item represents the major developer for that item. Of course all changes involve community discussion and patch review so each item is truely a community activity. First-name-only entries represent established developers, while full names represent newer contributors. I need help with the CVS section. Do we publish full CVS logs for a release? I like the SVN display because it groups commits but can improvements I listed above be made? -- 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 2: Don't 'kill -9' the postmaster
Re: [HACKERS] whats the deal with -u ?
"Tom Lane" <[EMAIL PROTECTED]> writes: > I don't remember why it's deprecated. The manual explains it: -u Forces psql to prompt for the user name and password before connecting to the database. This option is deprecated, as it is conceptually flawed. (Prompting for a non-default user name and prompting for a password because the server requires it are really two different things.) You are encouraged to look at the -U and -W options instead. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [COMMITTERS] pgsql: The E.
Simon Riggs <[EMAIL PROTECTED]> writes: > Don't want to shoot your Albatross, but those lines were written by > Coleridge. Must give the appropriate credits :-) Doh ... of course ... but why does Project Gutenberg have it filed under Wordsworth? http://www.gutenberg.org/etext/8905 Anyway, you are certainly correct; will go fix the attribution. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] whats the deal with -u ?
Gregory Stark <[EMAIL PROTECTED]> writes: > "Tom Lane" <[EMAIL PROTECTED]> writes: >> I don't remember why it's deprecated. > The manual explains it: > This option is deprecated, as it is conceptually flawed. (Prompting for a > non-default user name and prompting for a password because the server > requires it are really two different things.) You are encouraged to look > at the -U and -W options instead. Hmm. The point about the forced password prompt is certainly valid, but I see nothing wrong with the idea of having an option to prompt for the username. What if we just took out the forced password prompt, on the grounds that you can get that with "-u -W" if you want it? 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] Release Note Changes
Bruce Momjian wrote: Joshua D. Drake wrote: I assumed the white paper would have proper attribution. Right, but is the white paper going to be thorough to mention _all_ changes? Hmmm good question which gets back to where we started :). My very first thought on all of this was that we would list all notable changes but that we wouldn't mention anyone's name. Then, we would have a "Who contributed to this release" section that just listed names without attribution to the specific feature. IMO, that is the only "fair" way. I realize that notable is subjective. Here is the deal :). I think as long as a single person is making the decision as to what goes and stays, there will always be friction. Perhaps it is time for a "release team"? Odd numbers only, +1/-1 voting etc... I don't know maybe that is too much. Sincerely, Joshua D. Drake ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] whats the deal with -u ?
Tom Lane wrote: > Gregory Stark <[EMAIL PROTECTED]> writes: > > > The manual explains it: > > This option is deprecated, as it is conceptually flawed. (Prompting for > > a > > non-default user name and prompting for a password because the server > > requires it are really two different things.) You are encouraged to look > > at the -U and -W options instead. > > Hmm. The point about the forced password prompt is certainly valid, > but I see nothing wrong with the idea of having an option to prompt > for the username. What if we just took out the forced password prompt, > on the grounds that you can get that with "-u -W" if you want it? Yes, undeprecating it then makes sense. I have never understood what's the point of having an option to force a password prompt. I wonder why don't we deprecate -W? -- Alvaro Herrerahttp://www.advogato.org/person/alvherre "Cada quien es cada cual y baja las escaleras como quiere" (JMSerrat) ---(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] whats the deal with -u ?
Alvaro Herrera <[EMAIL PROTECTED]> writes: > I have never understood what's the point of having an option to force a > password prompt. I wonder why don't we deprecate -W? It's not *completely* useless, because you only need one connection attempt not two --- normally, psql gets rejected once before figuring out that it must ask for a password. You can imagine scenarios with slow internet connections, or a badly overloaded database, where it might be worth the keystrokes to type -W. OTOH, you can also avoid the two-attempts syndrome with a ~/.pgpass file. On balance I'm not for deprecating it, but pointing out that it's normally useless doesn't seem out of line... 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] whats the deal with -u ?
Alvaro Herrera wrote: Tom Lane wrote: Gregory Stark <[EMAIL PROTECTED]> writes: The manual explains it: This option is deprecated, as it is conceptually flawed. (Prompting for a non-default user name and prompting for a password because the server requires it are really two different things.) You are encouraged to look at the -U and -W options instead. Hmm. The point about the forced password prompt is certainly valid, but I see nothing wrong with the idea of having an option to prompt for the username. What if we just took out the forced password prompt, on the grounds that you can get that with "-u -W" if you want it? Yes, undeprecating it then makes sense. I have never understood what's the point of having an option to force a password prompt. I wonder why don't we deprecate -W? As I recall there was a bug under very specific circumstances that a password prompt would not appear. Thus we added the option for -W. Sincerely, Joshua D. Drake ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] pgsql: The E.
"Tom Lane" <[EMAIL PROTECTED]> writes: > Simon Riggs <[EMAIL PROTECTED]> writes: >> Don't want to shoot your Albatross, but those lines were written by >> Coleridge. Must give the appropriate credits :-) > > Doh ... of course ... but why does Project Gutenberg have it filed > under Wordsworth? > > http://www.gutenberg.org/etext/8905 > > Anyway, you are certainly correct; will go fix the attribution. oh phooey, this spoils what I was going to post. Worsworth would have proven a particularly ironic choice. He fought long and hard to extend copyright terms. http://links.jstor.org/sici?sici=0030-8129%28196109%2976%3A4%3C380%3AWATCAO%3E2.0.CO%3B2-P&size=LARGE&origin=JSTOR-enlargePage -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [DOCS] "distributed checkpoint"
Greg Smith wrote: > It's good this came up, because that is factually wrong; while the average > case is much better some OS-dependant aspects of the spike (what happens at > fsync) are certainly still there. I think it's easier to rewrite this > whole thing so it's technically accurate rather than a simple fix of the > wording, something like this: > > "Checkpoint writes can be spread over a longer time period to smooth the > I/O spike during each checkpoint" Thanks, I changed it to this. -- Alvaro Herrerahttp://www.advogato.org/person/alvherre "No necesitamos banderas No reconocemos fronteras" (Jorge González) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] whats the deal with -u ?
"Tom Lane" <[EMAIL PROTECTED]> writes: > Alvaro Herrera <[EMAIL PROTECTED]> writes: >> I have never understood what's the point of having an option to force a >> password prompt. I wonder why don't we deprecate -W? > > It's not *completely* useless, because you only need one connection > attempt not two --- normally, psql gets rejected once before figuring > out that it must ask for a password. Hm, I wonder if this fixes one of the annoyances of kerberos support. If you have kerberos tickets psql uses the principal name from them rather than your unix username. If you don't actually use kerberos authentication for your postgres server then that means you have to specify the user on the command line all the time. Don't actually have a psql built with kerberos authentication handy but I'll try to remember to test this the next time I do. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] whats the deal with -u ?
Gregory Stark wrote: > "Tom Lane" <[EMAIL PROTECTED]> writes: > > > Alvaro Herrera <[EMAIL PROTECTED]> writes: > >> I have never understood what's the point of having an option to force a > >> password prompt. I wonder why don't we deprecate -W? > > > > It's not *completely* useless, because you only need one connection > > attempt not two --- normally, psql gets rejected once before figuring > > out that it must ask for a password. > > Hm, I wonder if this fixes one of the annoyances of kerberos support. If you > have kerberos tickets psql uses the principal name from them rather than your > unix username. If you don't actually use kerberos authentication for your > postgres server then that means you have to specify the user on the command > line all the time. Huh, isn't this solved by just setting PGUSER? (In any case I doubt -W has any effect on it.) -- Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1", W 73º 13' 56.4" "La vida es para el que se aventura" ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [BUGS] BUG #3799: csvlog skips some logs
Andrew Dunstan wrote: > OK, works for me. I'll try to look at it after I have attended to the > Windows build issues. My plate is pretty full right now, though. FYI I'm having a look at it now. -- Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4 "Llegará una época en la que una investigación diligente y prolongada sacará a la luz cosas que hoy están ocultas" (Séneca, siglo I) ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [BUGS] BUG #3799: csvlog skips some logs
Alvaro Herrera wrote: Andrew Dunstan wrote: OK, works for me. I'll try to look at it after I have attended to the Windows build issues. My plate is pretty full right now, though. FYI I'm having a look at it now. Great. Thanks. cheers andrew ---(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] Release Note Changes
On Dec 10, 2007 10:39 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote: I like the realease notes intro. You may have already picked up on these, but a couple typos: > A names appearing next to an item represents the major developer for > that item. Of course all changes involve community discussion and > patch > review so each item is truely a community activity. First-name-only > entries represent established developers, while full names represent > newer contributors. "A names" -> "Names", "represents" -> "represent", "developer" -> "developers" or "developer(s)" if you prefer. I could really go a language that doesn't distinguish between singular and plural, but looks like we're stuck with English for the duration. And "truely" -> "truly". Cheers, BJ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] whats the deal with -u ?
"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > As I recall there was a bug under very specific circumstances that a > password prompt would not appear. Thus we added the option for -W. I don't see any evidence for that theory in the CVS logs .. Peter seems to have invented -W out of whole cloth. 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] Release Note Changes
On Dec 8, 2007 3:42 AM, Andrew Dunstan <[EMAIL PROTECTED]> wrote: > > > Bruce Momjian wrote: > > Andrew Dunstan wrote: > > > I still think this needs to be qualified either way. As it stands > it's > quite misleading. Many update scenarios will not benefit one whit > from > HOT updates. > > > >>> Doesn't the detail description qualify it enought? The heading isn't > >>> suppose to have all the information or it would be unreadable. > >>> > >>> > >>> > >> If you don't want to be more specific I'd say "certain updates" or > "some > >> updates" or something similar, just some flag to say it's not all of > them. > >> > > > > Good idea. I added "most": > > > >Heap-Only Tuples (HOT) accelerate space reuse for > most > >UPDATEs (Pavan Deolasee, with ideas from many others) > > > > But that's not true either. For example, in my current $dayjob app not > one significant update will benefit - we have an index rich environment. > You have no basis for saying "most" that I can see. We really should not > be in the hyp business in our release notes - that job belongs to the > commercial promoters ;-) > > > I don't agree completely. HOT updates is just one significant benefit of HOT and is constrained by the non-index column updates. But the other major benefit of truncating the tuples to their line pointers applies to HOT as well as COLD updates and DELETEs. This should also have a non trivial positive impact on the performance. There might be few scenarios where HOT may not show any improvement such as CPU-bound applications, but I am not sure if its worth mentioning. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com
Re: [HACKERS] Release Note Changes
> --- Original Message --- > From: Bruce Momjian <[EMAIL PROTECTED]> > To: Bruce Momjian <[EMAIL PROTECTED]> > Sent: 09/12/07, 23:39:55 > Subject: Re: [HACKERS] Release Note Changes > > First-name-only > entries represent established developers, while full names represent > newer contributors. That's inaccurate - I've been listed by full name for at least the last 3 or 4 releases. I realise I'm not the biggest contributor to the core code, but 'newer' certainly isn't right. /D ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
