Re: [PATCHES] Interval month, week - day
On Sep 1, 2006, at 9:32 , Tom Lane wrote: Michael Glaesemann [EMAIL PROTECTED] writes: On Sep 1, 2006, at 9:12 , Tom Lane wrote: I agree that this seems like an oversight in the original months/days/seconds patch, rather than behavior we want to keep. But is DecodeInterval the only place with the problem? I'll check on this tonight. Any idea where I might start to look? I'd look at the input routines for all the datetime types and see where they go. It's entirely possible that DecodeInterval is the only place with the problem, but I'd not assume that without looking. AFAICS, DecodeInterval is the only place that needed changing. I've looked through datetime.c, timestamp.c, date.c, and nabstime.c, and don't see anything else. It makes sense, too, as the only place where you could have weeks or non-integer months is during Interval input or interval multiplication/division. The pg_tm struct, which is used in time(stamp)?(tz)?/interval arithmetic only has integral months and no weeks component, so that shouldn't cause any problems. So, I think that's about it. Michael Glaesemann grzm seespotcode net ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] plpgsql, return can contains any expression
Hello I am sending corrected version. regards Pavel Stehule While this patch has new regression tests, it doesn't have new expected output for it. Please update the patch to supply that. Thanks. --- Pavel Stehule wrote: Hello This patch allows using any row expression in return statement and does transformation from untyped row to composite types if it's necessary. Regards Pavel Stehule _ Chcete sdilet sve obrazky a hudbu s prateli? http://messenger.msn.cz/ [ Attachment, skipping... ] ---(end of broadcast)--- TIP 6: explain analyze is your friend -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.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 _ Chcete sdilet sve obrazky a hudbu s prateli? http://messenger.msn.cz/ return.diff Description: application/binary ---(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: [PATCHES] [HACKERS] Interval aggregate regression failure (expected seems
On Sep 3, 2006, at 12:34 , Bruce Momjian wrote: OK, I worked with Michael and I think this is the best we are going to do to fix this. It has one TSROUND call for Powerpc, and that is documented. Applied. As I was working up regression tests, I found a case that this patch doesn't handle. select interval '4 mon' * .3 as product_h; product_h --- 1 mon 5 days 24:00:00 (1 row) This should be 1 mon 6 days. It fails for any number of months greater than 3 that is not evenly divisible by 10, greater than 3 months. Do we need to look at the month remainder separately? Michael Glaesemann grzm seespotcode net ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] [COMMITTERS] pgsql: Change FETCH/MOVE
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: There is *no* credible use case for this (hint: MOVE FORWARD/BACKWARD ALL does not need this to work for 2G tables). Already done because of bad coding. You want the TODO item removed too? As I said, I see no use case for it. Maybe if Moore's Law holds up for another five or ten years, it'll look like a useful feature then ... Removed. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.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: [PATCHES] [HACKERS] Interval aggregate regression failure
Is this non-datetime integer only or both? I cannot reproduce the failure here. --- Michael Glaesemann wrote: On Sep 3, 2006, at 12:34 , Bruce Momjian wrote: OK, I worked with Michael and I think this is the best we are going to do to fix this. It has one TSROUND call for Powerpc, and that is documented. Applied. As I was working up regression tests, I found a case that this patch doesn't handle. select interval '4 mon' * .3 as product_h; product_h --- 1 mon 5 days 24:00:00 (1 row) This should be 1 mon 6 days. It fails for any number of months greater than 3 that is not evenly divisible by 10, greater than 3 months. Do we need to look at the month remainder separately? Michael Glaesemann grzm seespotcode net -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.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: [PATCHES] [HACKERS] Interval aggregate regression failure (expected seems
Bruce Momjian [EMAIL PROTECTED] writes: Is this non-datetime integer only or both? I cannot reproduce the failure here. On HPPA with float datetimes with today's code, Michael's case works but it took me less than two minutes to find one that doesn't: regression=# select interval '14 mon' * 8.2 as product_h; product_h - 9 years 6 mons 23 days 24:00:00 (1 row) I reiterate my comment that this approach will never work; any small amount of experimentation will turn up cases that don't round correctly on one platform or another. Float arithmetic is inherently inexact. 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: [PATCHES] [HACKERS] Interval aggregate regression failure
Michael Glaesemann wrote: On Sep 3, 2006, at 12:34 , Bruce Momjian wrote: OK, I worked with Michael and I think this is the best we are going to do to fix this. It has one TSROUND call for Powerpc, and that is documented. Applied. As I was working up regression tests, I found a case that this patch doesn't handle. select interval '4 mon' * .3 as product_h; product_h --- 1 mon 5 days 24:00:00 (1 row) This should be 1 mon 6 days. It fails for any number of months greater than 3 that is not evenly divisible by 10, greater than 3 months. Do we need to look at the month remainder separately? Another question. Is this result correct? test= select '999 months 999 days'::interval / 100; ?column? - 9 mons 38 days 40:33:36 (1 row) Should that be: 9 mons 39 days 16:33:36 The core problem is that the combined remainder seconds of months and days is 24 hours. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.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: [PATCHES] Concurrent connections in psql patch
Bruce Momjian [EMAIL PROTECTED] writes: Is this something people are interested in? I am thinking no based on the lack of requests and the size of the patch. Lack of requests? I was actually surprised by how enthusiastically people reacted to it. However I don't think the patch as is is ready to be committed. Aside from missing documentation and regression tests it was only intended to be a proof-of-concept and to be useful for specific tests I was doing. I did try to do a decent job, I got \timing and server-tracked variables like encoding. But I need to go back through the code and make sure there are no other details like that. It would be nice to get feedback from other developers from looking at the patch to confirm that there aren't more fundamental problems with the approach and how it uses libpq before I go through the effort of cleaning up the details. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(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: [PATCHES] [HACKERS] Interval aggregate regression failure (expected seems
On Sep 4, 2006, at 4:45 , Bruce Momjian wrote: Another question. Is this result correct? test= select '999 months 999 days'::interval / 100; ?column? - 9 mons 38 days 40:33:36 (1 row) Should that be: 9 mons 39 days 16:33:36 Yeah, I think it should be. I had been thinking of treating the month and day component as having separate time contributions, but it makes more sense to think of month as a collection of days first, integral or no, and then cascade down the fractional portion of the combined days component to time. I.e., 9.99 mon is 9 mon 29.7 days, rather than 9 mon 29 days 60480 sec. Michael Glaesemann grzm seespotcode net ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] pgstattuple extension for indexes
Bruce Momjian [EMAIL PROTECTED] writes: Patch applied. Thanks. For some reason I expected this patch to correct the portability errors and design problems identified here: http://archives.postgresql.org/pgsql-patches/2006-07/msg00100.php Not only has it not fixed anything, it's made things worse: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g -fpic -I. -I../../src/include -D_GNU_SOURCE -c -o pgstattuple.o pgstattuple.c pgstattuple.c: In function 'pgstat_btree': pgstattuple.c:335: warning: format '%llu' expects type 'long long unsigned int', but argument 2 has type 'uint64' pgstattuple.c:335: warning: format '%llu' expects type 'long long unsigned int', but argument 3 has type 'uint64' pgstattuple.c:335: warning: format '%llu' expects type 'long long unsigned int', but argument 4 has type 'uint64' gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g -fpic -I. -I../../src/include -D_GNU_SOURCE -c -o pgstatindex.o pgstatindex.c pgstatindex.c: In function 'bt_page_items': pgstatindex.c:564: warning: format '%d' expects type 'int', but argument 4 has type 'long unsigned int' pgstatindex.c:564: warning: format '%d' expects type 'int', but argument 4 has type 'long unsigned int' ar crs libpgstattuple.a pgstattuple.o pgstatindex.o The only reason the buildfarm isn't crashing on this contrib module is that it lacks any regression test to crash on. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] pgstattuple extension for indexes
Thanks Bruce, Here are updated Japanese README, and uninstall_pgstattuple.sql. Bruce Momjian wrote: Patch applied. Thanks. I updated the README documentation for the new functions, attached. I could not update the Japanese version of the README. --- Satoshi Nagayasu wrote: Bruce, Attached patch has been cleaned up, and modified to be able to work with CVS HEAD. Thanks. Satoshi Nagayasu wrote: Alvaro, Alvaro Herrera wrote: Huh, I bet it works with 8.1.4, but it doesn't work on CVS HEAD: /pgsql/source/00orig/contrib/pgstattuple/pgstatindex.c: In function 'GetBTPageStatistics': /pgsql/source/00orig/contrib/pgstattuple/pgstatindex.c:182: error: 'BTItem' undeclared (first use in this function) While you're at it, please consider removing C++ style comments and unused code. Formatting is way off as well, but I guess that is easily fixed with pgindent. Thanks for comments. I'm going to fix my patch from now. Regarding the pg_relpages function, why do you think it's necessary? (It returns the true number of blocks of a given relation). It may belong into core given a reasonable use case, but otherwise it doesn't seem to belong into pgstatindex (or pgstattuple for that matter). I wanted to sample some pages from the table/index, and get their statistics to know table/index conditions. I know pgstattuple() reports table statistics, however, pgstattuple() generates heavy CPU and I/O load. When we need to sample some pages from table/index, we need to know true number of blocks. I have another function, called pgstatpage(), to get information inside a single block/page statistics of the table. pg_relpages() will be used with this. Sorry for not mentioned in previous post about pgstatpage(), but I've remembered about it just now. Many memories in my brain have already `paged-out` (too busy in last few months), and some of them got `out-of-memory`. :^) Thanks. -- NAGAYASU Satoshi [EMAIL PROTECTED] Phone: +81-3-3523-8122 diff -ruN pgstattuple.orig/Makefile pgstattuple/Makefile --- pgstattuple.orig/Makefile2006-02-27 21:54:40.0 +0900 +++ pgstattuple/Makefile 2006-08-14 09:28:58.0 +0900 @@ -6,7 +6,7 @@ # #- -SRCS= pgstattuple.c +SRCS= pgstattuple.c pgstatindex.c MODULE_big = pgstattuple OBJS= $(SRCS:.c=.o) diff -ruN pgstattuple.orig/pgstatindex.c pgstattuple/pgstatindex.c --- pgstattuple.orig/pgstatindex.c 1970-01-01 09:00:00.0 +0900 +++ pgstattuple/pgstatindex.c2006-08-14 11:24:23.0 +0900 @@ -0,0 +1,706 @@ +/* + * pgstatindex + * + * Copyright (c) 2006 Satoshi Nagayasu [EMAIL PROTECTED] + * + * Permission to use, copy, modify, and distribute this software and + * its documentation for any purpose, without fee, and without a + * written agreement is hereby granted, provided that the above + * copyright notice and this paragraph and the following two + * paragraphs appear in all copies. + * + * IN NO EVENT SHALL THE AUTHOR BE LIABLE TO ANY PARTY FOR DIRECT, + * INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING + * LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS + * DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED + * OF THE POSSIBILITY OF SUCH DAMAGE. + * + * THE AUTHOR SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR + * A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN AS + * IS BASIS, AND THE AUTHOR HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, + * SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS. + */ + +#include postgres.h + +#include fmgr.h +#include funcapi.h +#include access/heapam.h +#include access/itup.h +#include access/nbtree.h +#include access/transam.h +#include catalog/namespace.h +#include catalog/pg_type.h +#include utils/builtins.h +#include utils/inval.h + +PG_FUNCTION_INFO_V1(pgstatindex); +PG_FUNCTION_INFO_V1(bt_metap); +PG_FUNCTION_INFO_V1(bt_page_items); +PG_FUNCTION_INFO_V1(bt_page_stats); +PG_FUNCTION_INFO_V1(pg_relpages); + +extern Datum pgstatindex(PG_FUNCTION_ARGS); +extern Datum bt_metap(PG_FUNCTION_ARGS); +extern Datum bt_page_items(PG_FUNCTION_ARGS); +extern Datum bt_page_stats(PG_FUNCTION_ARGS); +extern Datum pg_relpages(PG_FUNCTION_ARGS); + +#define PGSTATINDEX_TYPE public.pgstatindex_type +#define PGSTATINDEX_NCOLUMNS 10 + +#define BTMETAP_TYPE public.bt_metap_type +#define BTMETAP_NCOLUMNS 6 + +#define BTPAGEITEMS_TYPE public.bt_page_items_type +#define BTPAGEITEMS_NCOLUMNS 6 + +#define BTPAGESTATS_TYPE public.bt_page_stats_type +#define BTPAGESTATS_NCOLUMNS 11 + + +#define IS_INDEX(r) ((r)-rd_rel-relkind == 'i') +#define IS_BTREE(r)
Re: [PATCHES] pgstattuple extension for indexes
Tom Lane wrote: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g -fpic -I. -I../../src/include -D_GNU_SOURCE -c -o pgstatindex.o pgstatindex.c pgstatindex.c: In function 'bt_page_items': pgstatindex.c:564: warning: format '%d' expects type 'int', but argument 4 has type 'long unsigned int' pgstatindex.c:564: warning: format '%d' expects type 'int', but argument 4 has type 'long unsigned int' I guess my '%d' should be '%zd', right? -- NAGAYASU Satoshi [EMAIL PROTECTED] Phone: +81-3-3523-8122 *** pgstatindex.c 2006-09-03 02:05:29.0 +0900 --- pgstatindex.c.new 2006-09-04 08:22:42.0 +0900 *** *** 561,567 values[j] = palloc(32); snprintf(values[j++], 32, (%u,%u), blkno, itup-t_tid.ip_posid); values[j] = palloc(32); ! snprintf(values[j++], 32, %d, IndexTupleSize(itup)); values[j] = palloc(32); snprintf(values[j++], 32, %c, IndexTupleHasNulls(itup) ? 't' : 'f'); values[j] = palloc(32); --- 561,567 values[j] = palloc(32); snprintf(values[j++], 32, (%u,%u), blkno, itup-t_tid.ip_posid); values[j] = palloc(32); ! snprintf(values[j++], 32, %zd, IndexTupleSize(itup)); values[j] = palloc(32); snprintf(values[j++], 32, %c, IndexTupleHasNulls(itup) ? 't' : 'f'); values[j] = palloc(32); ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Interval month, week - day
On Sep 3, 2006, at 20:00 , Michael Glaesemann wrote:
On Sep 1, 2006, at 9:32 , Tom Lane wrote:
Michael Glaesemann [EMAIL PROTECTED] writes:
On Sep 1, 2006, at 9:12 , Tom Lane wrote:
I agree that this seems like an oversight in the original
months/days/seconds patch, rather than behavior we want to keep.
But is DecodeInterval the only place with the problem?
I'll check on this tonight. Any idea where I might start to look?
I'd look at the input routines for all the datetime types and see
where
they go. It's entirely possible that DecodeInterval is the only
place
with the problem, but I'd not assume that without looking.
AFAICS, DecodeInterval is the only place that needed changing. I've
looked through datetime.c, timestamp.c, date.c, and nabstime.c, and
don't see anything else. It makes sense, too, as the only place
where you could have weeks or non-integer months is during Interval
input or interval multiplication/division. The pg_tm struct, which
is used in time(stamp)?(tz)?/interval arithmetic only has integral
months and no weeks component, so that shouldn't cause any
problems. So, I think that's about it.
I realized there might be something in ecpg, and there was. I've
updated the ecpg DecodeInterval to match. However, I haven't been
able to get ecpg make check to work, so that part's untested.
Michael Glaesemann
grzm seespotcode net
Index: src/backend/utils/adt/datetime.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/datetime.c,v
retrieving revision 1.169
diff -c -r1.169 datetime.c
*** src/backend/utils/adt/datetime.c25 Jul 2006 03:51:21 - 1.169
--- src/backend/utils/adt/datetime.c3 Sep 2006 23:55:34 -
***
*** 2920,2935
tm-tm_mday += val * 7;
if (fval != 0)
{
! int
sec;
!
! fval *= 7 *
SECS_PER_DAY;
! sec = fval;
! tm-tm_sec += sec;
#ifdef HAVE_INT64_TIMESTAMP
! *fsec += (fval - sec) *
100;
#else
! *fsec += fval - sec;
#endif
}
tmask = (fmask DTK_M(DAY)) ?
0 : DTK_M(DAY);
break;
--- 2920,2942
tm-tm_mday += val * 7;
if (fval != 0)
{
! int extra_days;
! fval *= 7;
! extra_days = (int32)
fval;
! tm-tm_mday +=
extra_days;
! fval -= extra_days;
! if (fval != 0)
! {
! int
sec;
! fval *=
SECS_PER_DAY;
! sec = fval;
! tm-tm_sec +=
sec;
#ifdef HAVE_INT64_TIMESTAMP
! *fsec += (fval
- sec) * 100;
#else
! *fsec += fval -
sec;
#endif
+ }
}
tmask = (fmask DTK_M(DAY)) ?
0 : DTK_M(DAY);
break;
***
*** 2938,2953
tm-tm_mon += val;
if (fval != 0)
{
! int
sec;
!
! fval *= DAYS_PER_MONTH
* SECS_PER_DAY;
! sec = fval;
! tm-tm_sec += sec;
#ifdef HAVE_INT64_TIMESTAMP
! *fsec += (fval - sec) *
100;
#else
! *fsec
Re: [PATCHES] Interval month, week - day
Michael Glaesemann [EMAIL PROTECTED] writes: I realized there might be something in ecpg, and there was. I've updated the ecpg DecodeInterval to match. However, I haven't been able to get ecpg make check to work, so that part's untested. This patch fails to apply --- looks like whitespace got mangled in transit. Please resend as an attachment. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Interval month, week - day
On Sep 4, 2006, at 9:41 , Tom Lane wrote: This patch fails to apply --- looks like whitespace got mangled in transit. Please resend as an attachment. Please let me know if you have any problems with this one. Michael Glaesemann grzm seespotcode net 10interval_input_0904T0855+0900.diff Description: Binary data ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] Interval aggregate regression failure
Michael Glaesemann wrote: On Sep 4, 2006, at 4:45 , Bruce Momjian wrote: Another question. Is this result correct? test= select '999 months 999 days'::interval / 100; ?column? - 9 mons 38 days 40:33:36 (1 row) Should that be: 9 mons 39 days 16:33:36 Yeah, I think it should be. I had been thinking of treating the month and day component as having separate time contributions, but it makes more sense to think of month as a collection of days first, integral or no, and then cascade down the fractional portion of the combined days component to time. I.e., 9.99 mon is 9 mon 29.7 days, rather than 9 mon 29 days 60480 sec. No, I don't think so. If we do that, there is no reason to cascade at all. Why not just say 9.1 months? I am going to work on a patch to fix the 24 hours case, which will fix your 24:00:00 case at the same time. Will post in an hour. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.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: [PATCHES] [HACKERS] Interval aggregate regression failure
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Is this non-datetime integer only or both? I cannot reproduce the failure here. On HPPA with float datetimes with today's code, Michael's case works but it took me less than two minutes to find one that doesn't: regression=# select interval '14 mon' * 8.2 as product_h; product_h - 9 years 6 mons 23 days 24:00:00 (1 row) I reiterate my comment that this approach will never work; any small amount of experimentation will turn up cases that don't round correctly on one platform or another. Float arithmetic is inherently inexact. Working on a new patch to round; will post. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.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] [PATCHES] Interval month, week - day
Michael Glaesemann [EMAIL PROTECTED] writes: On Sep 4, 2006, at 9:41 , Tom Lane wrote: This patch fails to apply --- looks like whitespace got mangled in transit. Please resend as an attachment. Please let me know if you have any problems with this one. Ah, that one works --- applied. A few comments: * You worried about the tmask coding in your original message, but I think that's OK as-is. The point of that code, IIUC, is to reject multiple specifications of the same field type, eg '1 day 2 days'. If we changed it then we'd reject '1.5 month 2 days', whereas I think least surprise would dictate adding the components to give 1 month 17 days. * AFAICT the ecpg regression tests are not affected by this change. * You mentioned being unable to get the ecpg tests to run on your machine. I'm sure Michael and Joachim would like the details. The ecpg regression tests are pretty new and some portability problems are to be expected, but they seem to be passing on all the machines Michael and Joachim and I have access to. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] pgstattuple extension for indexes
Bruce Momjian [EMAIL PROTECTED] wrote: Patch applied. Thanks. The two attached patches fix contrib/pgstattuple. pgstattuple.c.diff removes the fragmemtation reporting in pgstattuple(). It is no longer needed, because pgstatindex() has upward functionality now. Also, the report using elog was judged as improper in earlier discusses. pgstattuple.sql.in.diff removes DROP statements in the installer. The DROP statements make some unpleasant ERROR logs during install. According to other contrib modules, DROPs should be in the uninstaller and should not be in the installer. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center pgstattuple.sql.in.diff Description: Binary data pgstattuple.c.diff Description: Binary data ---(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] [PATCHES] Interval month, week - day
Tom Lane wrote: You mentioned being unable to get the ecpg tests to run on your machine. I'm sure Michael and Joachim would like the details. The ecpg regression tests are pretty new and some portability problems are to be expected, but they seem to be passing on all the machines Michael and Joachim and I have access to. I have just today released a new version of the buildfarm client that includes ECPG regression testing for HEAD (until now that was in our CVS tip but not in a released version). cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] pgstattuple extension for indexes
ITAGAKI Takahiro [EMAIL PROTECTED] writes: The two attached patches fix contrib/pgstattuple. Good, applied. I made some additional changes to get install/uninstall/ reinstall to work cleanly after the latest additions, and to get it to compile without warnings on a 64-bit Fedora machine. (It seems to actually work there, too.) I notice that the original pgstattuple() function comes in two flavors, one with OID input and one with text-relation-name input. Shouldn't all the others be likewise? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] pgstattuple extension for indexes
Satoshi Nagayasu [EMAIL PROTECTED] writes: Tom Lane wrote: pgstatindex.c: In function 'bt_page_items': pgstatindex.c:564: warning: format '%d' expects type 'int', but argument 4 has type 'long unsigned int' I guess my '%d' should be '%zd', right? No, that sounds even less portable :-( Given the expected range of IndexTupleSize(), it seems sufficient to cast its result to int and then use %d formatting. I've done that in the latest commit. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] python / 7.4 / FC5 / x86_64
and here is the forgotten patch
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
Ideally, we would get Python to tell us the right location, because
use lib64 if it exists isn't the right solution.
Is this fixed somewhere post 7.4?
Yes, but it was never backported. See:
http://developer.postgresql.org/cvsweb.cgi/pgsql/config/python.m4
My recollection is that there are a number of interrelated changes going
on there, and that a backport would have to touch a lot more than just
the python stuff. So I'd recommend that it's not worth the
trouble/risk.
But if you want to have a go at extracting a small patch from the CVS
history, have at it.
Patch attached - seems to work on my FC5/x86_64 box. Also contains the
OSX fix backported. Not sure that it qualifies as small though :-)
Unless there's an objection I will apply this soon (when were we
thinking of putting out the new point releases?)
--(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
cheers
andrew
Index: configure
===
RCS file: /projects/cvsroot/pgsql/configure,v
retrieving revision 1.310.2.24
diff -c -r1.310.2.24 configure
*** configure 21 May 2006 21:54:01 - 1.310.2.24
--- configure 4 Sep 2006 01:52:36 -
***
*** 4405,4453
fi
! echo $as_me:$LINENO: checking Python installation directories 5
! echo $ECHO_N checking Python installation directories... $ECHO_C 6
! python_version=`${PYTHON} -c import sys; print sys.version[:3]`
! python_prefix=`${PYTHON} -c import sys; print sys.prefix`
! python_execprefix=`${PYTHON} -c import sys; print sys.exec_prefix`
! python_configdir=${python_execprefix}/lib/python${python_version}/config
! python_includespec=-I${python_prefix}/include/python${python_version}
! if test $python_prefix != $python_execprefix; then
! python_includespec=-I${python_execprefix}/include/python${python_version} $python_includespec
fi
# This should be enough of a message.
! if test $python_prefix != $python_execprefix; then
! echo $as_me:$LINENO: result: $python_prefix/lib/python${python_version} and $python_execprefix/lib/python${python_version} 5
! echo ${ECHO_T}$python_prefix/lib/python${python_version} and $python_execprefix/lib/python${python_version} 6
! else
! echo $as_me:$LINENO: result: $python_prefix/lib/python${python_version} 5
! echo ${ECHO_T}$python_prefix/lib/python${python_version} 6
! fi
echo $as_me:$LINENO: checking how to link an embedded Python application 5
echo $ECHO_N checking how to link an embedded Python application... $ECHO_C 6
! if test ! -f $python_configdir/Makefile; then
! echo $as_me:$LINENO: result: no 5
! echo ${ECHO_T}no 6
! { { echo $as_me:$LINENO: error: Python Makefile not found 5
! echo $as_me: error: Python Makefile not found 2;}
!{ (exit 1); exit 1; }; }
! fi
! _python_libs=`grep '^LIBS=' $python_configdir/Makefile | sed 's/^.*=//'`
! _python_libc=`grep '^LIBC=' $python_configdir/Makefile | sed 's/^.*=//'`
! _python_libm=`grep '^LIBM=' $python_configdir/Makefile | sed 's/^.*=//'`
! _python_liblocalmod=`grep '^LOCALMODLIBS=' $python_configdir/Makefile | sed 's/^.*=//'`
! _python_libbasemod=`grep '^BASEMODLIBS=' $python_configdir/Makefile | sed 's/^.*=//'`
! pgac_tab= # tab character
! python_libspec=`echo X-L$python_configdir $_python_libs $_python_libc $_python_libm -lpython$python_version $_python_liblocalmod $_python_libbasemod | sed -e 's/^X//' -e s/[ $pgac_tab][ $pgac_tab]*/ /g`
! echo $as_me:$LINENO: result: ${python_libspec} 5
! echo ${ECHO_T}${python_libspec} 6
fi
--- 4405,4457
fi
! echo $as_me:$LINENO: checking for Python distutils module 5
! echo $ECHO_N checking for Python distutils module... $ECHO_C 6
! if ${PYTHON} 2- -c 'import distutils'
! then
! echo $as_me:$LINENO: result: yes 5
! echo ${ECHO_T}yes 6
! else
! echo $as_me:$LINENO: result: no 5
! echo ${ECHO_T}no 6
! { { echo $as_me:$LINENO: error: distutils module not found 5
! echo $as_me: error: distutils module not found 2;}
!{ (exit 1); exit 1; }; }
fi
+ echo $as_me:$LINENO: checking Python configuration directory 5
+ echo $ECHO_N checking Python configuration directory... $ECHO_C 6
+ python_version=`${PYTHON} -c import sys; print sys.version[:3]`
+ python_configdir=`${PYTHON} -c from distutils.sysconfig import get_python_lib as f; import os; print os.path.join(f(plat_specific=1,standard_lib=1),'config')`
+ python_includespec=`${PYTHON} -c import distutils.sysconfig; print '-I'+distutils.sysconfig.get_python_inc()`
# This should be enough of a message.
! echo $as_me:$LINENO: result: $python_configdir 5
! echo ${ECHO_T}$python_configdir
Re: [PATCHES] [HACKERS] Interval aggregate regression failure
Bruce Momjian wrote:
Michael Glaesemann wrote:
On Sep 3, 2006, at 12:34 , Bruce Momjian wrote:
OK, I worked with Michael and I think this is the best we are going to
do to fix this. It has one TSROUND call for Powerpc, and that is
documented. Applied.
As I was working up regression tests, I found a case that this patch
doesn't handle.
select interval '4 mon' * .3 as product_h;
product_h
---
1 mon 5 days 24:00:00
(1 row)
This should be 1 mon 6 days. It fails for any number of months
greater than 3 that is not evenly divisible by 10, greater than 3
months. Do we need to look at the month remainder separately?
Another question. Is this result correct?
test= select '999 months 999 days'::interval / 100;
?column?
-
9 mons 38 days 40:33:36
(1 row)
Should that be:
9 mons 39 days 16:33:36
The core problem is that the combined remainder seconds of months and
days is 24 hours.
OK, updated patch. It will fix the =24:00:00 case because it cascades
up if the remainder number of seconds is greater or equal to one day.
One open item is that it still might show 24 hours if the seconds
computation combined with the remaning seconds 24 hours. Not sure if
that should be handled or not. If you fix that, you really are
cascading up because the resulting seconds might be less than the
computed value, e.g. result is 23:00:00, remainder is 02:00:00, cascade
up would be 1 day, 01:00:00. I am unsure we want to do that. Right
now, this will show 25:00:00.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: src/backend/utils/adt/timestamp.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/adt/timestamp.c,v
retrieving revision 1.166
diff -c -c -r1.166 timestamp.c
*** src/backend/utils/adt/timestamp.c 3 Sep 2006 03:34:04 - 1.166
--- src/backend/utils/adt/timestamp.c 4 Sep 2006 03:49:21 -
***
*** 2525,2541
sec_remainder = (orig_day * (double)SECS_PER_DAY) * factor -
result-day * (double)SECS_PER_DAY +
(month_remainder_days - (int32) month_remainder_days) * SECS_PER_DAY;
/* cascade units down */
result-day += (int32) month_remainder_days;
#ifdef HAVE_INT64_TIMESTAMP
result-time = rint(span-time * factor + sec_remainder * USECS_PER_SEC);
#else
! /*
! * TSROUND() needed to prevent -146:23:60.00 output on PowerPC for
! * SELECT interval '-41 mon -12 days -360:00' * 0.3;
! */
! result-time = span-time * factor + TSROUND(sec_remainder);
#endif
PG_RETURN_INTERVAL_P(result);
--- 2524,2547
sec_remainder = (orig_day * (double)SECS_PER_DAY) * factor -
result-day * (double)SECS_PER_DAY +
(month_remainder_days - (int32) month_remainder_days) * SECS_PER_DAY;
+ /*
+ * Might have 24:00:00 hours due to rounding, or 24 hours because of
+ * time cascade from months and days. It might still be 24 if the
+ * combination of cascade and the seconds factor operation itself.
+ */
+ sec_remainder = TSROUND(sec_remainder);
+ if (Abs(sec_remainder) = SECS_PER_DAY)
+ {
+ sec_remainder -= (int)(sec_remainder / SECS_PER_DAY) * SECS_PER_DAY;
+ result-day += (int)(sec_remainder / SECS_PER_DAY);
+ }
/* cascade units down */
result-day += (int32) month_remainder_days;
#ifdef HAVE_INT64_TIMESTAMP
result-time = rint(span-time * factor + sec_remainder * USECS_PER_SEC);
#else
! result-time = span-time * factor + sec_remainder;
#endif
PG_RETURN_INTERVAL_P(result);
***
*** 2579,2584
--- 2585,2596
sec_remainder = (orig_day * (double)SECS_PER_DAY) / factor -
result-day * (double)SECS_PER_DAY +
(month_remainder_days - (int32) month_remainder_days) * SECS_PER_DAY;
+ sec_remainder = TSROUND(sec_remainder);
+ if (Abs(sec_remainder) = SECS_PER_DAY)
+ {
+ sec_remainder -= (int)(sec_remainder / SECS_PER_DAY) * SECS_PER_DAY;
+ result-day += (int)(sec_remainder / SECS_PER_DAY);
+ }
/* cascade units down */
result-day += (int32) month_remainder_days;
***
*** 2586,2592
result-time = rint(span-time / factor + sec_remainder * USECS_PER_SEC);
#else
/* See TSROUND comment in interval_mul(). */
! result-time = span-time / factor + TSROUND(sec_remainder);
#endif
PG_RETURN_INTERVAL_P(result);
--- 2598,2604
result-time = rint(span-time / factor + sec_remainder * USECS_PER_SEC);
#else
/* See TSROUND comment in interval_mul(). */
! result-time = span-time / factor + sec_remainder;
#endif
PG_RETURN_INTERVAL_P(result);
Index: src/include/utils/timestamp.h
===
RCS file: /cvsroot/pgsql/src/include/utils/timestamp.h,v
retrieving revision 1.62
diff -c -c -r1.62
