Re: [HACKERS] [PATCHES] Interval month, week -> day
Tom Lane wrote:
> Michael Meskes <[EMAIL PROTECTED]> writes:
> > On Sun, Sep 03, 2006 at 10:21:11PM -0400, Bruce Momjian wrote:
> >> When I tried the ecpg regression tests it complained there was no
> >> results/ directory. I created one and it worked.
>
> > Hmm, anyone else experiencing this? The pg_regress.sh has this code that
> > should create it:
>
> > outputdir="results/"
>
> > if [ ! -d "$outputdir" ]; then
> > mkdir -p "$outputdir" || { (exit 2); exit; }
> > fi
>
> I'll bet you should lose the slash in $outputdir. test(1) might or
> might not be "friendly" about stripping that off.
Yep, I saw this error:
mkdir: results/: No such file or directory
gmake: *** [installcheck] Error 2
I have removed the trailing slash from CVS; tests run fine now.
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 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [HACKERS] [PATCHES] Interval month, week -> day
Michael Meskes <[EMAIL PROTECTED]> writes:
> On Sun, Sep 03, 2006 at 10:21:11PM -0400, Bruce Momjian wrote:
>> When I tried the ecpg regression tests it complained there was no
>> results/ directory. I created one and it worked.
> Hmm, anyone else experiencing this? The pg_regress.sh has this code that
> should create it:
> outputdir="results/"
> if [ ! -d "$outputdir" ]; then
> mkdir -p "$outputdir" || { (exit 2); exit; }
> fi
I'll bet you should lose the slash in $outputdir. test(1) might or
might not be "friendly" about stripping that off.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [HACKERS] [PATCHES] Interval month, week -> day
On Sun, Sep 03, 2006 at 10:21:11PM -0400, Bruce Momjian wrote:
> When I tried the ecpg regression tests it complained there was no
> results/ directory. I created one and it worked.
Hmm, anyone else experiencing this? The pg_regress.sh has this code that
should create it:
outputdir="results/"
if [ ! -d "$outputdir" ]; then
mkdir -p "$outputdir" || { (exit 2); exit; }
fi
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 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: > 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. When I tried the ecpg regression tests it complained there was no results/ directory. I created one and it worked. -- 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
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: [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 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [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: [HACKERS] [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 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
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
!
Re: [HACKERS] [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 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Interval month, week -> day
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. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] Interval month, week -> day
On Sep 1, 2006, at 9:12 , Tom Lane wrote: Michael Glaesemann <[EMAIL PROTECTED]> writes: I came across some behavior that seems counterintuitive to me: test=# select '1.5 mon'::interval; interval - 1 mon 360:00:00 (1 row) With the time/day/month interval struct introduced in 8.1, I'd expect this to return '1 mon 15 days'. The reason is that the DecodeInterval converts fractional months to time directly, rather than cascading first to days. 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? My recollection is that there's a certain amount of redundancy in the datetime code ... I'll check on this tonight. Any idea where I might start to look? Michael Glaesemann grzm seespotcode net ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Interval month, week -> day
Michael Glaesemann <[EMAIL PROTECTED]> writes: > I came across some behavior that seems counterintuitive to me: > test=# select '1.5 mon'::interval; > interval > - > 1 mon 360:00:00 > (1 row) > With the time/day/month interval struct introduced in 8.1, I'd expect > this to return '1 mon 15 days'. The reason is that the DecodeInterval > converts fractional months to time directly, rather than cascading > first to days. 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? My recollection is that there's a certain amount of redundancy in the datetime code ... regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
