[PATCHES] Removal of backward-compatibility docs mentions
The attached patch removes or minimizes some documentation mentions of backward compatibility for release 7.2 and earlier. I have not altered any mentions of release 7.3 or later. The release notes were not modified, so the changes are still documented, just not in the main docs. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. + Index: doc/src/sgml/array.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/array.sgml,v retrieving revision 1.48 diff -c -c -r1.48 array.sgml *** doc/src/sgml/array.sgml 19 Nov 2005 01:50:08 - 1.48 --- doc/src/sgml/array.sgml 20 Mar 2006 18:40:41 - *** *** 559,566 embedded in element values will be backslash-escaped. For numeric data types it is safe to assume that double quotes will never appear, but for textual data types one should be prepared to cope with either presence !or absence of quotes. (This is a change in behavior from pre-7.2 !productnamePostgreSQL/productname releases.) /para para --- 559,565 embedded in element values will be backslash-escaped. For numeric data types it is safe to assume that double quotes will never appear, but for textual data types one should be prepared to cope with either presence !or absence of quotes. /para para Index: doc/src/sgml/backup.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v retrieving revision 2.79 diff -c -c -r2.79 backup.sgml *** doc/src/sgml/backup.sgml10 Mar 2006 19:10:46 - 2.79 --- doc/src/sgml/backup.sgml20 Mar 2006 18:40:42 - *** *** 1211,1218 the number after the first dot changes). This does not apply to different minor releases under the same major release (where the number after the second dot changes); these always have compatible !storage formats. For example, releases 7.0.1, 7.1.2, and 7.2 are !not compatible, whereas 7.1.1 and 7.1.2 are. When you update between compatible versions, you can simply replace the executables and reuse the data directory on disk. Otherwise you need to back up your data and restore it on the new server. This has to be done --- 1211,1218 the number after the first dot changes). This does not apply to different minor releases under the same major release (where the number after the second dot changes); these always have compatible !storage formats. For example, releases 7.2.1, 7.3.2, and 7.4 are !not compatible, whereas 7.2.1 and 7.2.2 are. When you update between compatible versions, you can simply replace the executables and reuse the data directory on disk. Otherwise you need to back up your data and restore it on the new server. This has to be done Index: doc/src/sgml/config.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/config.sgml,v retrieving revision 1.52 diff -c -c -r1.52 config.sgml *** doc/src/sgml/config.sgml10 Mar 2006 19:10:47 - 1.52 --- doc/src/sgml/config.sgml20 Mar 2006 18:40:44 - *** *** 3789,3801 listitem para This controls the inheritance semantics, in particular whether ! subtables are included by various commands by default. They were ! not included in versions prior to 7.1. If you need the old ! behavior you can set this variable to literaloff/, but in ! the long run you are encouraged to change your applications to ! use the literalONLY/literal key word to exclude subtables. ! See xref linkend=ddl-inherit for more information about ! inheritance. /para /listitem /varlistentry --- 3789,3796 listitem para This controls the inheritance semantics, in particular whether ! subtables are included by various commands by default. This was ! added for compatibility with releases prior to 7.1. /para /listitem /varlistentry Index: doc/src/sgml/datatype.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v retrieving revision 1.166 diff -c -c -r1.166 datatype.sgml *** doc/src/sgml/datatype.sgml 10 Mar 2006 19:10:47 - 1.166 --- doc/src/sgml/datatype.sgml 20 Mar 2006 18:40:46 - *** *** 894,915 string. /para ! para ! If one explicitly casts a value to typecharacter ! varying(replaceablen/)/type or ! typecharacter(replaceablen/)/type, then an over-length ! value will be truncated to replaceablen/ characters without ! raising an error. (This too is required by the ! acronymSQL/acronym standard.)
Re: [PATCHES] Removal of backward-compatibility docs mentions
[ Sorry for the two copies, Bruce: I forgot to CC the list previously ] On Mon, 2006-03-20 at 13:57 -0500, Bruce Momjian wrote: The attached patch removes or minimizes some documentation mentions of backward compatibility for release 7.2 and earlier. I don't think it's a net win to get rid of this text, as it describes useful alternatives to the GUC variable: *** doc/src/sgml/config.sgml10 Mar 2006 19:10:47 - 1.52 --- doc/src/sgml/config.sgml20 Mar 2006 18:40:44 - *** *** 3789,3801 listitem para This controls the inheritance semantics, in particular whether ! subtables are included by various commands by default. They were ! not included in versions prior to 7.1. If you need the old ! behavior you can set this variable to literaloff/, but in ! the long run you are encouraged to change your applications to ! use the literalONLY/literal key word to exclude subtables. ! See xref linkend=ddl-inherit for more information about ! inheritance. /para /listitem /varlistentry --- 3789,3796 listitem para This controls the inheritance semantics, in particular whether ! subtables are included by various commands by default. This was ! added for compatibility with releases prior to 7.1. /para /listitem /varlistentry *** doc/src/sgml/libpq.sgml 10 Mar 2006 19:10:48 - 1.206 --- doc/src/sgml/libpq.sgml 20 Mar 2006 18:41:05 - *** *** 689,699 functions described below to get at the contents of structnamePGconn/structname. Avoid directly referencing the fields of the structnamePGconn/ structure because they are subject to change in the future. - (Beginning in productnamePostgreSQL/productname release 6.4, the - definition of the typestruct/type behind structnamePGconn/ is not even provided in filenamelibpq-fe.h/filename. - If you have old code that accesses structnamePGconn/structname fields directly, you can keep using it - by including filenamelibpq-int.h/filename too, but you are encouraged to fix the code - soon.) /para /tip Removing the information about libpq-int.h but keeping the suggestion to avoid directly referencing fields of the PGconn structure doesn't seem consistent: the user *can't* directly reference fields without including libpq-int.h. So I think this hunk should be kept. The second hunk modified in maintenance.sgml removes some useful information (ANALYZE collects rows by random sampling). From storage.sgml: ! Since productnamePostgreSQL/productname uses a fixed page size (commonly ! 8Kb), and does not allow tuples to span multiple pages, so it's not possible to ! store very large field values directly. That is poorly phrased (Since ..., so it's not). -Neil ---(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
[PATCHES] Additional current timestamp values
I hBrendan Jurd wrote: On 8/7/05, Brendan Jurd [EMAIL PROTECTED] wrote: Hi all, I propose to add an internal function gettime() that transparently returns the current system time, as a timestamptz with maximum precision. Rather than applying the above patch, I have implemented this TODO with the attached patch: * Add transaction_timestamp(), statement_timestamp(), clock_timestamp() functionality Current CURRENT_TIMESTAMP returns the start time of the current transaction, and gettimeofday() returns the wallclock time. This will make time reporting more consistent and will allow reporting of the statement start time. I questioned whether we need transaction_timestamp() because it is the same as CURRENT_TIMESTAMP and now(), but added this to the docs: functionCURRENT_TIMESTAMP/ might not be the transaction start time on other database systems. For this reason, and for completeness, functiontransaction_timestamp/ is provided. The overhead of this patch is an additional gettimeofday() call for each statement in a multi-statement transaction. We already do a gettimeofday() for each transaction, even single-statement transactions. I see no way to avoid the additional function call. One trick is that these should be the same: test= SELECT statement_timestamp(), transaction_timestamp(); statement_timestamp | transaction_timestamp ---+--- 2006-03-20 16:59:33.790335-05 | 2006-03-20 16:59:33.790335-05 (1 row) and these should be different: test= BEGIN; BEGIN test= select statement_timestamp(), transaction_timestamp(); statement_timestamp | transaction_timestamp ---+--- 2006-03-20 16:59:55.347467-05 | 2006-03-20 16:59:54.520446-05 (1 row) And these should be the same: $ psql -c ' INSERT INTO t VALUES (statement_timestamp()); INSERT INTO t VALUES (statement_timestamp());' test INSERT 0 1 $ psql test Welcome to psql 8.2devel, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit test= SELECT * FROM t; x --- 2006-03-20 17:06:02.057077-05 2006-03-20 17:06:02.057077-05 (2 rows) And they all work. Is there a cleaner method than the one I have used? I have also improved the documentation so it is clearer what value is returned by each current data/time function. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. + Index: doc/src/sgml/func.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/func.sgml,v retrieving revision 1.313 diff -c -c -r1.313 func.sgml *** doc/src/sgml/func.sgml 10 Mar 2006 20:15:25 - 1.313 --- doc/src/sgml/func.sgml 17 Mar 2006 20:04:27 - *** *** 5303,5308 --- 5303,5317 primarynow/primary /indexterm indexterm + primarytransaction_timestamp/primary +/indexterm +indexterm + primarystatement_timestamp/primary +/indexterm +indexterm + primaryclock_timestamp/primary +/indexterm +indexterm primarytimeofday/primary /indexterm *** *** 5358,5364 row entryliteralfunctioncurrent_timestamp/function/literal/entry entrytypetimestamp with time zone/type/entry ! entryDate and time; see xref linkend=functions-datetime-current /entry entry/entry entry/entry --- 5367,5373 row entryliteralfunctioncurrent_timestamp/function/literal/entry entrytypetimestamp with time zone/type/entry ! entryDate and time of start of current transaction; see xref linkend=functions-datetime-current /entry entry/entry entry/entry *** *** 5474,5481 row entryliteralfunctionnow/function()/literal/entry entrytypetimestamp with time zone/type/entry ! entryCurrent date and time (equivalent to ! functioncurrent_timestamp/function); see xref linkend=functions-datetime-current /entry entry/entry entry/entry --- 5483,5518 row entryliteralfunctionnow/function()/literal/entry entrytypetimestamp with time zone/type/entry ! entryDate and time of start of current transaction (equivalent to !
Re: [PATCHES] Additional current timestamp values
Bruce Momjian wrote: Rather than applying the above patch, I have implemented this TODO with the attached patch: * Add transaction_timestamp(), statement_timestamp(), clock_timestamp() functionality The most common complaint that I recall is that current_timestamp returns the transaction timestamp rather than the statement timestamp, which is what many expect. How does your patch address that? Do we really need clock_timestamp? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Removal of backward-compatibility docs mentions
Neil Conway [EMAIL PROTECTED] writes: I don't think it's a net win to get rid of this text, as it describes useful alternatives to the GUC variable: I was about to object to some other parts of the patch on the same grounds, in particular the changes to ddl.sgml and maintenance.sgml, and the first change in xfunc.sgml. In most of these cases, currently-useful information is intertwined with the reference to the old behavior. If you can't be bothered to rewrite to preserve all of the information, then don't remove the text. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Additional current timestamp values
Peter Eisentraut wrote: Bruce Momjian wrote: Rather than applying the above patch, I have implemented this TODO with the attached patch: * Add transaction_timestamp(), statement_timestamp(), clock_timestamp() functionality The most common complaint that I recall is that current_timestamp returns the transaction timestamp rather than the statement timestamp, which is what many expect. How does your patch address that? No, we believe the standard requires it. Do we really need clock_timestamp? Yes, because timeofday() returns a unix text string. Some people do want a wallclock current timestamp. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Removal of backward-compatibility docs mentions
Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: I don't think it's a net win to get rid of this text, as it describes useful alternatives to the GUC variable: I was about to object to some other parts of the patch on the same grounds, in particular the changes to ddl.sgml and maintenance.sgml, and the first change in xfunc.sgml. In most of these cases, currently-useful information is intertwined with the reference to the old behavior. If you can't be bothered to rewrite to preserve all of the information, then don't remove the text. I am working on Neils suggestion. I don't agree we need to preserve all information about very old releases. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.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: [PATCHES] Additional current timestamp values
Bruce Momjian wrote: functionCURRENT_TIMESTAMP/ might not be the transaction start time on other database systems. For this reason, and for completeness, functiontransaction_timestamp/ is provided. Well, transaction_timestamp() is even more unlikely to be the transaction start time on other database systems :) If the user wants non-standard syntax for getting the timestamp at which the current transaction began, we already have now(). One trick is that these should be the same: test= SELECT statement_timestamp(), transaction_timestamp(); Should they be? It seems quite reasonable to me that the DBMS begins a transaction internally (setting transaction_timestamp()), and then a short while later begins executing the statement submitted by the user, at which point statement_timestamp() is set. Perhaps ensuring they are identical for single-statement transactions is the best behavior, I just don't think this is required behavior. And these should be the same: $ psql -c ' INSERT INTO t VALUES (statement_timestamp()); INSERT INTO t VALUES (statement_timestamp());' test INSERT 0 1 Uh, why should these be the same? -Neil ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Additional current timestamp values
Bruce Momjian wrote: Peter Eisentraut wrote: The most common complaint that I recall is that current_timestamp returns the transaction timestamp rather than the statement timestamp, which is what many expect. How does your patch address that? No, we believe the standard requires it. My copy of SQL 200n has the following to say: Annex C, paragraph 16: The time of evaluation of the CURRENT_DATE, CURRENT_TIME, and CURRENT_TIMESTAMP functions during the execution of an SQL-statement is implementation-dependent. 6.31, datetime value function: (1) The datetime value functions CURRENT_DATE, CURRENT_TIME, and CURRENT_TIMESTAMP respectively return the current date, current time, and current timestamp; the time and timestamp values are returned with time zone displacement equal to the current default time zone displacement of the SQL-session. [...] (2) Let S be an SQL procedure statement that is not generally contained in a triggered action. All datetime value functions that are contained in value expressions that are generally contained, without an intervening routine invocation whose subject routines do not include an SQL function, either in S without an intervening SQL procedure statement or in an SQL procedure statement contained in the triggered action of a trigger activated as a consequence of executing S, are effectively evaluated simultaneously. The time of evaluation of a datetime value function during the execution of S and its activated triggers is implementation-dependent. -Neil ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Removal of backward-compatibility docs mentions
Bruce Momjian pgman@candle.pha.pa.us writes: Tom Lane wrote: currently-useful information is intertwined with the reference to the old behavior. If you can't be bothered to rewrite to preserve all of the information, then don't remove the text. I am working on Neils suggestion. I don't agree we need to preserve all information about very old releases. That's not what I complained about. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Additional current timestamp values
Neil Conway wrote: Bruce Momjian wrote: functionCURRENT_TIMESTAMP/ might not be the transaction start time on other database systems. For this reason, and for completeness, functiontransaction_timestamp/ is provided. Well, transaction_timestamp() is even more unlikely to be the transaction start time on other database systems :) If the user wants non-standard syntax for getting the timestamp at which the current transaction began, we already have now(). True, which is why I brought it up. I think a good argument can be made that we don't need two non-standard ways of specifying the transaction timestamp, but we need to decide that as a group. One trick is that these should be the same: test= SELECT statement_timestamp(), transaction_timestamp(); Should they be? It seems quite reasonable to me that the DBMS begins a transaction internally (setting transaction_timestamp()), and then a short while later begins executing the statement submitted by the user, at which point statement_timestamp() is set. Perhaps ensuring they are identical for single-statement transactions is the best behavior, I just don't think this is required behavior. Yea, perhaps it isn't required, but it seems like a good idea. It will avoid confusion and seems logical. :-) And these should be the same: $ psql -c ' INSERT INTO t VALUES (statement_timestamp()); INSERT INTO t VALUES (statement_timestamp());' test INSERT 0 1 Uh, why should these be the same? This gets into cases where a single statement generates more than one parsenode, e.g. rules. We want all the parse nodes to have the same timestamp. We had a long discussion that the statement time isn't really meaningful/logical, so I went with code that said the statement arrival time is the proper time to return, and be consistent. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Additional current timestamp values
Neil Conway wrote: Bruce Momjian wrote: Peter Eisentraut wrote: The most common complaint that I recall is that current_timestamp returns the transaction timestamp rather than the statement timestamp, which is what many expect. How does your patch address that? No, we believe the standard requires it. My copy of SQL 200n has the following to say: Annex C, paragraph 16: The time of evaluation of the CURRENT_DATE, CURRENT_TIME, and CURRENT_TIMESTAMP functions during the execution of an SQL-statement is implementation-dependent. 6.31, datetime value function: (1) The datetime value functions CURRENT_DATE, CURRENT_TIME, and CURRENT_TIMESTAMP respectively return the current date, current time, and current timestamp; the time and timestamp values are returned with time zone displacement equal to the current default time zone displacement of the SQL-session. [...] (2) Let S be an SQL procedure statement that is not generally contained in a triggered action. All datetime value functions that are contained in value expressions that are generally contained, without an intervening routine invocation whose subject routines do not include an SQL function, either in S without an intervening SQL procedure statement or in an SQL procedure statement contained in the triggered action of a trigger activated as a consequence of executing S, are effectively evaluated simultaneously. The time of evaluation of a datetime value function during the execution of S and its activated triggers is implementation-dependent. OK, so we just decided transaction timestamp is the most logical value for CURRENT_TIMESTAMP. Anyway, this might mean we should have transaction_timestamp for completeness. Not sure. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.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: [PATCHES] Additional current timestamp values
Neil Conway [EMAIL PROTECTED] writes: Bruce Momjian wrote: One trick is that these should be the same: test= SELECT statement_timestamp(), transaction_timestamp(); Should they be? ISTM that the most useful definition of statement_timestamp is really time of arrival of the latest interactive command from the client, and as such it should not be tied to statement start per se at all. I'd be in favor of doing gettimeofday() upon receiving a client message, reporting that value directly for statement_timestamp, and copying it during transaction start to obtain the value to use for transaction_timestamp. I don't much like the idea of doing a gettimeofday() per SQL statement, especially not if that's taken to mean every SQL statement issued by PL functions (and if it doesn't mean that, statement_timestamp seems like the wrong name). One gettimeofday() per client message doesn't seem too horrible though, since that's certainly going to require at least a couple of kernel calls anyway. Possibly we should call it command_timestamp not statement_timestamp to help reduce confusion. The patch as given strikes me as pretty broken --- it does not advance statement_timestamp when I would expect (AFAICS it only sets it during transaction start). I don't like it stylistically either: ISTM either these things are the responsibility of xact.c or they are the responsibility of postgres.c, it is not sensible to have both modules assigning to statement_timestamp. BTW, now that I look at it, the statement_timeout GUC variable seems to have much of the same confusion about whether statement is equivalent to interactive command or not. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Additional current timestamp values
Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: Bruce Momjian wrote: One trick is that these should be the same: test= SELECT statement_timestamp(), transaction_timestamp(); Should they be? ISTM that the most useful definition of statement_timestamp is really time of arrival of the latest interactive command from the client, and as such it should not be tied to statement start per se at all. I see your point. I'd be in favor of doing gettimeofday() upon receiving a client message, reporting that value directly for statement_timestamp, and copying it during transaction start to obtain the value to use for transaction_timestamp. I don't much like the idea of doing a gettimeofday() per SQL statement, especially not if that's taken to mean every SQL statement issued by PL functions (and if it doesn't mean that, statement_timestamp seems like the wrong name). One gettimeofday() per client message doesn't seem too horrible though, since that's certainly going to require at least a couple of kernel calls anyway. Possibly we should call it command_timestamp not statement_timestamp to help reduce confusion. The patch as given strikes me as pretty broken --- it does not advance statement_timestamp when I would expect (AFAICS it only sets it during transaction start). I don't like it stylistically either: ISTM either Uh, it does advance: test= BEGIN; BEGIN test= SELECT statement_timestamp(), transaction_timestamp(); statement_timestamp | transaction_timestamp --+--- 2006-03-20 18:49:17.88062-05 | 2006-03-20 18:49:11.922934-05 (1 row) test= SELECT statement_timestamp(), transaction_timestamp(); statement_timestamp | transaction_timestamp ---+--- 2006-03-20 18:49:19.176823-05 | 2006-03-20 18:49:11.922934-05 (1 row) start_xact_command() is kind of badly worded. It calls StartTransactionCommand(), which might or might not start a transaction, then it does statement_timeout setup. I have always been confused if statement_timeout times queries inside server-side functions, for example. I don't think it should. these things are the responsibility of xact.c or they are the responsibility of postgres.c, it is not sensible to have both modules assigning to statement_timestamp. It was done to minimize code change and limit the number of gettimeofday() calls. BTW, now that I look at it, the statement_timeout GUC variable seems to have much of the same confusion about whether statement is equivalent to interactive command or not. True. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.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: [PATCHES] Removal of backward-compatibility docs mentions
I have made the modifications you suggested. Any others? --- Neil Conway wrote: [ Sorry for the two copies, Bruce: I forgot to CC the list previously ] On Mon, 2006-03-20 at 13:57 -0500, Bruce Momjian wrote: The attached patch removes or minimizes some documentation mentions of backward compatibility for release 7.2 and earlier. I don't think it's a net win to get rid of this text, as it describes useful alternatives to the GUC variable: *** doc/src/sgml/config.sgml10 Mar 2006 19:10:47 - 1.52 --- doc/src/sgml/config.sgml20 Mar 2006 18:40:44 - *** *** 3789,3801 listitem para This controls the inheritance semantics, in particular whether ! subtables are included by various commands by default. They were ! not included in versions prior to 7.1. If you need the old ! behavior you can set this variable to literaloff/, but in ! the long run you are encouraged to change your applications to ! use the literalONLY/literal key word to exclude subtables. ! See xref linkend=ddl-inherit for more information about ! inheritance. /para /listitem /varlistentry --- 3789,3796 listitem para This controls the inheritance semantics, in particular whether ! subtables are included by various commands by default. This was ! added for compatibility with releases prior to 7.1. /para /listitem /varlistentry *** doc/src/sgml/libpq.sgml 10 Mar 2006 19:10:48 - 1.206 --- doc/src/sgml/libpq.sgml 20 Mar 2006 18:41:05 - *** *** 689,699 functions described below to get at the contents of structnamePGconn/structname. Avoid directly referencing the fields of the structnamePGconn/ structure because they are subject to change in the future. - (Beginning in productnamePostgreSQL/productname release 6.4, the - definition of the typestruct/type behind structnamePGconn/ is not even provided in filenamelibpq-fe.h/filename. - If you have old code that accesses structnamePGconn/structname fields directly, you can keep using it - by including filenamelibpq-int.h/filename too, but you are encouraged to fix the code - soon.) /para /tip Removing the information about libpq-int.h but keeping the suggestion to avoid directly referencing fields of the PGconn structure doesn't seem consistent: the user *can't* directly reference fields without including libpq-int.h. So I think this hunk should be kept. The second hunk modified in maintenance.sgml removes some useful information (ANALYZE collects rows by random sampling). From storage.sgml: ! Since productnamePostgreSQL/productname uses a fixed page size (commonly ! 8Kb), and does not allow tuples to span multiple pages, so it's not possible to ! store very large field values directly. That is poorly phrased (Since ..., so it's not). -Neil ---(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 -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. + Index: doc/src/sgml/array.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/array.sgml,v retrieving revision 1.48 diff -c -c -r1.48 array.sgml *** doc/src/sgml/array.sgml 19 Nov 2005 01:50:08 - 1.48 --- doc/src/sgml/array.sgml 20 Mar 2006 23:42:29 - *** *** 559,566 embedded in element values will be backslash-escaped. For numeric data types it is safe to assume that double quotes will never appear, but for textual data types one should be prepared to cope with either presence !or absence of quotes. (This is a change in behavior from pre-7.2 !productnamePostgreSQL/productname releases.) /para para --- 559,565 embedded in element values will be backslash-escaped. For numeric data types it is safe to assume that double quotes will never appear, but for textual data types one should be prepared to cope with either presence !or absence of quotes. /para para Index: doc/src/sgml/backup.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v retrieving revision 2.79 diff -c -c -r2.79 backup.sgml *** doc/src/sgml/backup.sgml10 Mar 2006 19:10:46 - 2.79 --- doc/src/sgml/backup.sgml20 Mar 2006 23:42:31 - *** *** 1211,1218 the number after the first dot changes).
Re: [PATCHES] PATCH to allow concurrent VACUUMs to not lock each
This is going to need a significant safety review. Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Hannu Krosing wrote: On K, 2005-08-17 at 15:40 -0400, Tom Lane wrote: Saatja: Tom Lane [EMAIL PROTECTED] Kellele: Bruce Momjian pgman@candle.pha.pa.us, Hannu Krosing [EMAIL PROTECTED], Neil Conway [EMAIL PROTECTED], pgsql- [EMAIL PROTECTED] Teema: Re: [PATCHES] PATCH to allow concurrent VACUUMs to not lock each Kuup?ev: Wed, 17 Aug 2005 15:40:53 -0400 (22:40 EEST) Just for the archives, attached is as far as I'd gotten with cleaning up Hannu's patch before I realized that it wasn't doing what it needed to do. This fixes an end-of-transaction race condition (can't unset inVacuum before xact end, unless you want OldestXmin going backwards from the point of view of other people) and improves the documentation of what's going on. But unless someone can convince me that it's safe to mess with GetSnapshotData, it's unlikely this'll ever get applied. Attached is a patch, based on you last one, which messes with GetSnapshotData in what I think is a safe way. It introduces another attribute to PROC , proc-nonInVacuumXmin and computes this in addition to prox-xmin inside GetSnapshotData. When (and only when) GetOldestXmin is called with ignoreVacuum=true, then proc-nonInVacuumXmin is checked instead of prox-xmin. I believe that this will make this change invisible to all other places where GetSnapshotData or GetOldestXmin is used. -- Hannu Krosing [EMAIL PROTECTED] [ Attachment, skipping... ] ---(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 -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.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: [PATCHES] FW: Win32 unicode vs ICU
Is this patch moving toward competion? --- Magnus Hagander wrote: I just realised this mail didn't go through. Probably because it was too large for -hackers. So: repost to -patches. Sorry about that. If it's a duplicate, even more sorry, but I couldn't find it in the archives. (This may explain that nobody answered me :P) //Magnus -Original Message- From: Magnus Hagander Sent: Sunday, July 31, 2005 2:09 PM To: PostgreSQL-development Cc: [EMAIL PROTECTED] Subject: Win32 unicode vs ICU Hi! I've been working with Palles ICU patch to make it work on win32, and I believe I have it done. While doing it I noticed that ICU basically converts to UTF16 and back - I previously thought it worked on UTF8 strings. Based on this I also tried out an implementation for the win32-unicode problem that does *not* require ICU. It uses the win32 native functions to map to utf16 and back, and then to process the text there. And I got through with much less code than the ICU version, while doing the same thing. I am unsure of how to proceed. As I see it there are three paths: 1) Use native win32 functionality only on win32 2) Use ICU functionality only on win32 3) Allow both ICU and native functionality, compile time switch --with-icu (same as unix with the ICU patch) The main downsides of ICU vs the native ones are: * ICU does not accept win32 locale names. When doing setlocale(sv_se), for example, win32 will return this in later calls as Swedish_Sweden.1252. To get around this in the ICU patch, I had to implement a lookup map that converts it back to sv_se for ICU. * ICU is yet another build and runtime dependency, and a large one (comes in at 11Mb for the DLL files alone in the win32 download) I guess that the main upside of it is that we'd get constistent behaviour - in case there are issues with either ICU or win32 native they'd otherwise differ. And only one new codepath. But we already live with the platform-inconsistency today... Another upside is that it handles more encodings in ICU - my native implementation does *only* UTF8 and relies on existing functionality to deal with other encodings. It could of course be extended if necessary, but from what I can tell UTF8 is the big one. I have attached both patches. For the native version, only win32_utf8.patch is required. For the ICU version, icu_win32.patch is needed and also the files localemap.c,localemap.pl, iso639 and iso3166 needs to go in src/backend/port/win32. (the localemap needs to be updated to do a better-than-linear search, but I wanted to include an example) Thoughts on the options? And anohter question - my native patch touches the same functions as the ICU patch. Can somebody who knows the internals confirm or deny that these are all the required locations, or do we need to modify more? (I have run simple tests in swedish locale and both behave the same and correct, but I'm unsure of exactly how much would be affected) Finally, the win32 patch also changes the normal path to use strncoll(). The comment above the function states that we'd like to use strncoll but it's not available. Well, on win32 it is, so it should provide a speedup on win32. It is currently not included in the ICU patch, but should probably be included whichever path we'd chose. //Magnus Content-Description: win32_utf8.patch [ Attachment, skipping... ] Content-Description: icu_win32.patch [ Attachment, skipping... ] Content-Description: localemap.pl [ Attachment, skipping... ] Content-Description: localemap.c [ Attachment, skipping... ] ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.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
