Re: [PATCHES] [HACKERS] Performance testing of COPY (SELECT) TO
On Mon, Aug 28, 2006 at 07:35:11PM +0200, Zoltan Boszormenyi wrote: > >>COPY (SELECT ...) (col1, col2, ...) TO > >>and it was actually working. In your v9 > >>you rewrote the syntax parsing so that > >>feature was lost in translation. > >> > > > >Interesting. I didn't realize this was possible -- obviously I didn't > >test it (did you have a test for it in the regression tests? I may have > >missed it). In fact, I deliberately removed the column list from the > >grammar, because it can certainly be controlled inside the SELECT, so I > >thought there was no reason the support controlling it in the COPY > >column list. > > > > Yes, it was even documented. I thought about having > queries stored statically somewhere (not in views) and > being able to use only part of the result. ISTM that there should have been a regression test that tried that capability out. That would have made it obvious when the functionality was lost, at least. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] log_statement output for protocol
Guillaume Smet wrote:
> On 8/29/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > Good point. I thought it was clear enough, but obviously not. I had a
> > similar case with bind, and used a comma to separate them:
> >
> > LOG: statement: prepare sel1, SELECT $1;
> > LOG: statement: bind sel1, $1 = 'a''b'
>
> For this one, I must admit I prefer the colon we used before.
> Something like:
> LOG: statement: prepare sel1: SELECT $1;
> LOG: statement: bind sel1: $1 = 'a''b'
> seems better to me as after the colon, we have the details of the
> command which is the common sense of a colon.
OK, done.
> > I am concerned a dash isn't clear enough, and a semicolon is confusing.
> > Using a comma the new output is:
> >
> > LOG: duration: 0.023 ms execute sel1
> > DETAIL: prepare: SELECT $1;, bind: $1 = 'a''b'
>
> A dash is clearer in this case IMHO. ;, is not very readable. But I
> can parse easily both forms so it's not a problem for me if you prefer
> a comma.
I thought about this, and because we are placing two pieces of
information on the same line, it seems "|" is the best choice.
> > Is that OK? Patch attached and committed. I also fixed the null bind
> > parameter bug. It now displays $1 = NULL (no quotes used).
>
> Cool. I'll test that.
>
> > Other suggestions?
>
> I'll compile this new version and make tests in the next few days to
> check everything is consistent and let you know.
>
> I'm still struggling to find a regexp good enough to parse "statement:
> execute y ('a', 4, 'text, with a comma'::text);" :).
Oh. You want to pull the parameters out of that. I am thinking you
need something that will go over the line character by character with
some type of state machine, rather than just regex.
> Thanks a lot for your work on this subject. It will help us a lot when
> we use the JDBC driver.
Patch attached and applied. New output:
LOG: statement: begin;
LOG: statement: prepare x as select $1::text;
LOG: statement: execute x ('a');
DETAIL: prepare: prepare x as select $1::text;
LOG: statement: commit;
LOG: statement: set log_statement = 'none';
LOG: duration: 0.222 ms statement: set log_min_duration_statement = 0;
LOG: duration: 0.061 ms statement: begin;
LOG: duration: 0.113 ms statement: prepare y as select $1::text;
LOG: duration: 0.213 ms statement: execute y ('a');
DETAIL: prepare: prepare y as select $1::text;
LOG: duration: 0.081 ms statement: commit;
LOG: statement: prepare sel1: SELECT $1;
LOG: statement: bind sel1: $1 = 'a''b'
DETAIL: prepare: SELECT $1;
LOG: statement: execute sel1
DETAIL: prepare: SELECT $1; | bind: $1 = 'a''b'
LOG: duration: 0.445 ms statement: SET log_min_duration_statement = 0;
LOG: duration: 0.018 ms execute sel1
DETAIL: prepare: SELECT $1; | bind: $1 = 'a''b'
Additional comments?
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: src/backend/tcop/postgres.c
===
RCS file: /cvsroot/pgsql/src/backend/tcop/postgres.c,v
retrieving revision 1.502
diff -c -c -r1.502 postgres.c
*** src/backend/tcop/postgres.c 29 Aug 2006 20:10:42 - 1.502
--- src/backend/tcop/postgres.c 30 Aug 2006 17:59:05 -
***
*** 1146,1152
if (log_statement == LOGSTMT_ALL)
ereport(LOG,
! (errmsg("statement: prepare %s, %s",
*stmt_name ? stmt_name : "",
query_string)));
--- 1146,1152
if (log_statement == LOGSTMT_ALL)
ereport(LOG,
! (errmsg("statement: prepare %s: %s",
*stmt_name ? stmt_name : "",
query_string)));
***
*** 1621,1627
*portal->name ? "/" : "",
*portal->name ? portal->name : "",
/* print bind parameters if we have them */
! bind_values_str.len ? ", " : "",
bind_values_str.len ? bind_values_str.data : ""),
errdetail("prepare: %s", pstmt->query_string)));
}
--- 1621,1627
*portal->name ? "/" : "",
*portal->name ? portal->name : "",
/* print bind parameters if we have them */
! bind_values_str.len ? ": " : "",
bind_values_str.len ? bind_values_str.data : ""),
errdetail("prepare: %s", pstmt->query_string)));
}
***
*** 1788,1794
*portal_name ? portal_name : ""),
errdetail("prepare: %s%s%s", sourceText,
/* optionally print bind parameters */
! bindText ? ", bind: " : "",
bindText ? bindText : "")));
BeginCommand(portal->commandTag, dest);
--- 1788,1794
*portal_name ? portal_name : ""),
errdetail("prepare: %s%s%s", sourceText,
/* optionally print bind parameters */
! bindText ? "
Re: [PATCHES] [HACKERS] Performance testing of COPY (SELECT) TO
=?iso-8859-2?Q?B=F6sz=F6rm=E9nyi_Zolt=E1n?= <[EMAIL PROTECTED]> writes: > as per your suggestion, the COPY view TO support was cut and > a hint was added. Please, review. Committed after some refactoring to avoid code duplication. Unfortunately, in a moment of pure brain fade, I looked at the wrong item in my inbox and wrote Bernd Helmle's name instead of yours in the commit message :-(. My sincere apologies. Bruce, would you make a note to be sure the right person gets credit in the release notes? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Performance testing of COPY (SELECT)
Tom Lane wrote: > =?iso-8859-2?Q?B=F6sz=F6rm=E9nyi_Zolt=E1n?= <[EMAIL PROTECTED]> writes: > > as per your suggestion, the COPY view TO support was cut and > > a hint was added. Please, review. > > Committed after some refactoring to avoid code duplication. > > Unfortunately, in a moment of pure brain fade, I looked at the wrong > item in my inbox and wrote Bernd Helmle's name instead of yours in the > commit message :-(. My sincere apologies. Bruce, would you make a note > to be sure the right person gets credit in the release notes? Fixed with new commit message to copy.c. -- 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] Performance testing of COPY (SELECT) TO
Thanks!!! Tom Lane írta: =?iso-8859-2?Q?B=F6sz=F6rm=E9nyi_Zolt=E1n?= <[EMAIL PROTECTED]> writes: as per your suggestion, the COPY view TO support was cut and a hint was added. Please, review. Committed after some refactoring to avoid code duplication. Unfortunately, in a moment of pure brain fade, I looked at the wrong item in my inbox and wrote Bernd Helmle's name instead of yours in the commit message :-(. My sincere apologies. Bruce, would you make a note to be sure the right person gets credit in the release notes? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] log_statement output for protocol
On 8/29/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Good point. I thought it was clear enough, but obviously not. I had a
similar case with bind, and used a comma to separate them:
LOG: statement: prepare sel1, SELECT $1;
LOG: statement: bind sel1, $1 = 'a''b'
For this one, I must admit I prefer the colon we used before.
Something like:
LOG: statement: prepare sel1: SELECT $1;
LOG: statement: bind sel1: $1 = 'a''b'
seems better to me as after the colon, we have the details of the
command which is the common sense of a colon.
I am concerned a dash isn't clear enough, and a semicolon is confusing.
Using a comma the new output is:
LOG: duration: 0.023 ms execute sel1
DETAIL: prepare: SELECT $1;, bind: $1 = 'a''b'
A dash is clearer in this case IMHO. ;, is not very readable. But I
can parse easily both forms so it's not a problem for me if you prefer
a comma.
Is that OK? Patch attached and committed. I also fixed the null bind
parameter bug. It now displays $1 = NULL (no quotes used).
Cool. I'll test that.
Other suggestions?
I'll compile this new version and make tests in the next few days to
check everything is consistent and let you know.
I'm still struggling to find a regexp good enough to parse "statement:
execute y ('a', 4, 'text, with a comma'::text);" :).
Thanks a lot for your work on this subject. It will help us a lot when
we use the JDBC driver.
--
Guillaume
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Changes to epgc test
On Tue, Aug 29, 2006 at 02:46:06PM -0400, Chris Browne wrote: > I'm not at all sure that these are the right changes to apply; it > somewhat appears to me as though ecpg is supposed to be able to cope > with the omissions. Yor're right. It should cope with those. The database names were ommitted by design. It seems to me that it is working on the few buildfarm machines that have it enabled so far. Mabye you still had an old preproc.y/preproc.c around? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] updated patch for selecting large results
On Tue, 2006-08-29 at 18:31 -0400, Tom Lane wrote: > <[EMAIL PROTECTED]> writes: > > here comes the latest version (version 7) of the patch to handle large > > result sets with psql. As previously discussed, a cursor is used > > for SELECT queries when \set FETCH_COUNT some_value > 0 > > Applied with revisions ... I didn't like the fact that the code was > restricted to handle only unaligned output format, so I fixed print.c > to be able to deal with emitting output in sections. This is not > ideal for aligned output mode, because we compute column widths > separately for each FETCH group, but all the other output modes work > nicely. I also did a little hacking to make \timing and pager output > work as expected. > > regards, tom lane Cool! I specially like that as a side effect of your work for applying this, psql is faster now. Thanks to all people that helped with this (lots...:) Bye, Chris. -- Chris Mair http://www.1006.org ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[PATCHES] Backend SSL configuration enhancement
This patch adds two new configuration diretives to postgresql.conf file
1. ssl_ciphers - allows server administrator to specify set of SSL
ciphersuites which can be used by clients to connect the server.
2. ssl_engine - allows to specify loadable crypto engin (i.e. hardware
crypto accelerator support) to use.
diff -crN ../pgsql-20060830/doc/src/sgml/config.sgml ./doc/src/sgml/config.sgml
*** ../pgsql-20060830/doc/src/sgml/config.sgml 2006-08-30 16:01:12.0
+0400
--- ./doc/src/sgml/config.sgml 2006-08-30 16:04:11.0 +0400
***
*** 555,561
!
password_encryption
(boolean)
--- 555,596
!
!ssl_ciphers> (string)
!
! ssl_ciphers configuration
parameter
!
!
!
! Specifies list of SSL ciphers, which can be used to
! establish secure connection. See manual page for
! openssl ciphers
! command to find list of allowed values and their semantics.
!
!
!
!
!ssl_engine (string)
!
! ssl_engine configuration
parameter
!
!
!
! Specifies name of OpenSSL engine (loadable
module),
! which should be used to perform cryptographic operation during
! SSL connections. Typically engines are used to
! support hardware cryptographic accelerators. See
! OpenSSL documentation for more information about
! engines.
!
!
! Value of this option is engine identifier. Deafault value is
! NULL, which means that default OpenSSL
! implementations of cryptoalgorithms should be used.
!
!
!
!
password_encryption
(boolean)
diff -crN ../pgsql-20060830/doc/src/sgml/runtime.sgml
./doc/src/sgml/runtime.sgml
*** ../pgsql-20060830/doc/src/sgml/runtime.sgml 2006-08-30 16:01:12.0
+0400
--- ./doc/src/sgml/runtime.sgml 2006-08-30 16:04:11.0 +0400
***
*** 1516,1521
--- 1516,1539
+ OpenSSL supports wide range of ciphers
+ and authentication algorithms, which strength varies significantly.
+ You can restrict list of ciphers which can be used to connect to
+ your server using parameter.
+
+
+
+ OpenSSL supports loadable module, called
+ engines, which can provide alternative (typically hardware
+ accelerated) implementation of cryptographic algorithms. Starting
+ with version 0.9.9 it also supports adding of new (for instance
+ Russian or Japanese national standards) cryptoalgorithms via engine.
+
+
+ PostgreSQL allows to specify engine to use via
+configuration file parameter.
+
+
For details on how to create your server private key and certificate,
refer to the OpenSSL documentation. A
self-signed certificate can be used for testing, but a
diff -crN ../pgsql-20060830/src/backend/libpq/be-secure.c
./src/backend/libpq/be-secure.c
*** ../pgsql-20060830/src/backend/libpq/be-secure.c 2006-08-30
16:01:28.0 +0400
--- ./src/backend/libpq/be-secure.c 2006-08-30 16:04:11.0 +0400
***
*** 92,97
--- 92,98
#ifdef USE_SSL
#include
#include
+ #include
#endif
#include "libpq/libpq.h"
***
*** 125,130
--- 126,136
#define RENEGOTIATION_LIMIT (512 * 1024 * 1024)
static SSL_CTX *SSL_context = NULL;
+
+ /* GUC variables contrilling SSL connection*/
+ extern char *SSLEngine;
+ extern char *SSLCipherSuites;
+
#endif
/* */
***
*** 714,724
--- 720,755
initialize_SSL(void)
{
struct stat buf;
+ static int loaded_engines=0;
if (!SSL_context)
{
SSL_library_init();
SSL_load_error_strings();
+ if (SSLEngine!=NULL)
+ {
+ ENGINE *e=NULL;
+ if (!loaded_engines)
+ {
+ ENGINE_load_builtin_engines();
+ loaded_engines=1;
+ }
+ if ((e = ENGINE_by_id(SSLEngine))==NULL)
+ {
+ ereport(FATAL,
+
(errcode(ERRCODE_CONFIG_FILE_ERROR),
+ errmsg("failed to load engine
%s: %s",
+
SSLEngine,ERR_error_string(ERR_get_error(),NULL;
+ }
+ if (!ENGINE_set_defa
Re: [PATCHES] [HACKERS] Interval aggregate regression failure (expected seems
On Aug 30, 2006, at 12:50 , Bruce Momjian wrote: Yea, I see that -122:23:60.00. After applying your patch, I believe that on my machine it's the contribution from the day component that is producing the 23:60.00. For example, select interval '-12 days' * 0.3; ?column? -- -3 days -14:23:60.00 (1 row) I think some kind of rounding needs to be done to the day contribution as well. I'm continuing to work on it, but wanted to get this out there. Michael Glaesemann grzm seespotcode net ---(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: [PATCHES] Backend SSL configuration enhancement
"Victor B. Wagner" <[EMAIL PROTECTED]> writes: > This patch adds two new configuration diretives to postgresql.conf file > 1. ssl_ciphers - allows server administrator to specify set of SSL > ciphersuites which can be used by clients to connect the server. > 2. ssl_engine - allows to specify loadable crypto engin (i.e. hardware > crypto accelerator support) to use. Why are either of these useful? What are the compatibility implications of changing them? Does the addition of the engine-load code break compatibility with older OpenSSL releases? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Backend SSL configuration enhancement
On 2006.08.30 at 10:14:02 -0400, Tom Lane wrote: > "Victor B. Wagner" <[EMAIL PROTECTED]> writes: > > This patch adds two new configuration diretives to postgresql.conf file > > 1. ssl_ciphers - allows server administrator to specify set of SSL > > ciphersuites which can be used by clients to connect the server. > > 2. ssl_engine - allows to specify loadable crypto engin (i.e. hardware > > crypto accelerator support) to use. > > Why are either of these useful? What are the compatibility implications First one is useful if for some reason some ciphers supported by OpenSSL is not permitted to use in the particular network, or if there is need to use ciphersuites which are not included into default ciphersuite list, now compiled into PostgreSQL. It might be requirement of enhanced security, or some national standards requirement. Or vice versa - people might want client certificates for authentication, but avoid encryption for performance reasons. Second one can be used for taking cryptography load from server into special hardware chip, which can be useful for loaded servers. Also, upcoming OpenSSL 0.9.9 allows to add entirely new cryptographic algorithms via engines, so engine support allows to use algorithms, i.e. national standards, which are not supported in the OpenSSL core. We have developed this patch in order to use Russian GOST algorithms for SSL connections. > of changing them? Does the addition of the engine-load code break > compatibility with older OpenSSL releases? Engines have appeared in OpenSSL quite a long ago. Version 0.9.7 already supports them. So, compatibility is broken only with 0.9.6 and eariler which have numerous other problems anyway. I can recheck my patch and add conditional compilation around engine loading code to be sure that it doesn't break compatiblity with 0.9.6, just ignores ssl_engine keyword if underlying OpenSSL doesn't support engines. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Updatable views
On Wed, Aug 30, 2006 at 12:01:25PM -0400, Tom Lane wrote: > Bernd Helmle <[EMAIL PROTECTED]> writes: > > [ latest views patch ] > > This is the first time I've actually looked at this patch, and I am > dismayed. viewUpdate.c looks like nothing so much as a large program > with a small program struggling to get out. What is all the stuff about > handling multiple base rels? SQL92, at least, does not say that a join > is updatable, and AFAICT this patch is rejecting that too ... though > it's hard to tell with the conditions for allowing the join to be > updatable scattered through a lot of different functions. And some of > the code seems to be expecting multiple implicit rules and other parts > not. I get the impression that a lot of this code is left over from a > more ambitious first draft and ought to be removed in the name of > readability/maintainability. If that code is on the right path to allowing things like updates to the many side of a join then it would be worth adding comments to that effect. Or maybe a comment referencing whatever version of the file the code was yanked out of. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Updatable views
Bernd Helmle <[EMAIL PROTECTED]> writes: > [ latest views patch ] This is the first time I've actually looked at this patch, and I am dismayed. viewUpdate.c looks like nothing so much as a large program with a small program struggling to get out. What is all the stuff about handling multiple base rels? SQL92, at least, does not say that a join is updatable, and AFAICT this patch is rejecting that too ... though it's hard to tell with the conditions for allowing the join to be updatable scattered through a lot of different functions. And some of the code seems to be expecting multiple implicit rules and other parts not. I get the impression that a lot of this code is left over from a more ambitious first draft and ought to be removed in the name of readability/maintainability. I'm unclear as to why you've got DO INSTEAD NOTHING rules in there --- the spec says that a WITH CHECK OPTION violation results in an error, not in nothing happening, so it doesn't seem to me that we should need any NOTHING rules to implement the spec. It would probably help if there were some header documentation that explained exactly how the module intends to transform a SELECT to create the various action rules. The pg_dump changes seem pretty odd too. Why wouldn't you just ignore implicit rules during a dump, expecting the system to regenerate them when the view is reloaded? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Interval aggregate regression failure
Michael Glaesemann wrote: > > Yea, just an optimization, but I was worried that the computations > > might > > throw problems for certain numbers, so I figured I would only > > trigger it > > when necessary. > > Thanks for the explanation. Helps me know I might actually be > learning this. > > > Patch attached. It also fixes a regression test output too. > > Thanks for the patch. I'll look at it more closely tonight. OK, here is a much nicer patch. The fix is to do no rounding, but to find the number of days before applying the factor adjustment. It passes all your tests here: test=> select '41 mon 10:00:00'::interval / 10 as "pos"; pos 4 mons 3 days 01:00:00 (1 row) test=> select interval '41 mon 12 days 360:00' * 0.3 as product_a , interval '41 mon -12 days -360:00' * 0.3 as product_b , interval '-41 mon 12 days 360:00' * 0.3 as product_c , interval '-41 mon -12 days -360:00' * 0.3 as product_d; product_a |product_b | product_c | product_d --+--+-+-- 1 year 12 days 122:24:00 | 1 year 6 days -122:24:00 | -1 years -6 days +122:24:00 | -1 years -12 days -122:24:00 (1 row) test=> select interval '41 mon 12 days 360:00' / 10 as quotient_a , interval '41 mon -12 days -360:00' / 10 as quotient_b , interval '-41 mon 12 days 360:00' / 10 as quotient_c , interval '-41 mon -12 days -360:00' / 10 as quotient_d; quotient_a | quotient_b|quotient_c |quotient_d +-+---+--- 4 mons 4 days 40:48:00 | 4 mons 2 days -40:48:00 | -4 mons -2 days +40:48:00 | -4 mons -4 days -40:48:00 (1 row) What do you see on your platform? -- 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.165 diff -c -c -r1.165 timestamp.c *** src/backend/utils/adt/timestamp.c 13 Jul 2006 16:49:16 - 1.165 --- src/backend/utils/adt/timestamp.c 30 Aug 2006 17:08:12 - *** *** 2496,2501 --- 2496,2502 day_remainder, month_remainder_days; Interval *result; + int32 orig_month = span->month; result = (Interval *) palloc(sizeof(Interval)); *** *** 2516,2523 * using justify_hours and/or justify_days. */ ! /* fractional months full days into days */ ! month_remainder_days = month_remainder * DAYS_PER_MONTH; result->day += (int32) month_remainder_days; /* fractional months partial days into time */ day_remainder += month_remainder_days - (int32) month_remainder_days; --- 2517,2533 * using justify_hours and/or justify_days. */ ! /* ! * Fractional months full days into days. ! * ! * The remainders suffer from float rounding, so instead of ! * doing the computation using just the remainder, we calculate ! * the total number of days and subtract. Specifically, we are ! * multipling by DAYS_PER_MONTH before dividing by factor. ! * This greatly reduces rounding errors. ! */ ! month_remainder_days = (orig_month * DAYS_PER_MONTH) * factor - ! result->month * DAYS_PER_MONTH; result->day += (int32) month_remainder_days; /* fractional months partial days into time */ day_remainder += month_remainder_days - (int32) month_remainder_days; *** *** 2550,2556 day_remainder, month_remainder_days; Interval *result; ! result = (Interval *) palloc(sizeof(Interval)); if (factor == 0.0) --- 2560,2567 day_remainder, month_remainder_days; Interval *result; ! int32 orig_month = span->month; ! result = (Interval *) palloc(sizeof(Interval)); if (factor == 0.0) *** *** 2566,2576 day_remainder -= result->day; /* ! * Handle any fractional parts the same way as in interval_mul. */ ! ! /* fractional months full days into days */ ! month_remainder_days = month_remainder * DAYS_PER_MONTH; result->day += (int32) month_remainder_days; /* fractional months partial days into time */ day_remainder += month_remainder_days - (int32) month_remainder_days; --- 2577,2587 day_remainder -= result->day; /* ! * Fractional months full days into days. See comment in ! * interval_mul(). */ ! month_remainder_days = (orig_month * DA
Re: [PATCHES] [HACKERS] Interval aggregate regression failure
Michael Glaesemann wrote: > > On Aug 30, 2006, at 12:50 , Bruce Momjian wrote: > > > Yea, I see that -122:23:60.00. > > After applying your patch, I believe that on my machine it's the > contribution from the day component that is producing the 23:60.00. > For example, > > select interval '-12 days' * 0.3; > ?column? > -- > -3 days -14:23:60.00 > (1 row) > > I think some kind of rounding needs to be done to the day > contribution as well. I'm continuing to work on it, but wanted to get > this out there. Please test with my new patch and let me know how it looks. Thanks. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
