On Thu, Mar 20, 2008 at 6:41 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Warren Turkal <[EMAIL PROTECTED]> writes:
> > I added TimeOffset and DateOffset typedefs to get rid of the instances
> > using the HAVE_INT64_TIMESTAMP define being used to determine the
> >
On Thu, Mar 20, 2008 at 6:48 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Warren Turkal" <[EMAIL PROTECTED]> writes:
>
> > I have to say, I am wondering more and more how real the need is for
> > the two representations of timestamps. Would it be better
On Thu, Mar 20, 2008 at 5:22 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Warren Turkal <[EMAIL PROTECTED]> writes:
>
> > Here's an initial bit of my attempt at cleaning up the the timestamp
> > datatype.
>
> I'm starting to work through this now. You
Is there anything I can do to help?
wt
On Tue, Mar 18, 2008 at 7:49 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Warren Turkal" <[EMAIL PROTECTED]> writes:
> > Give the discussion on this. Is this small patch being considered for
> > inclusion? If not
Give the discussion on this. Is this small patch being considered for
inclusion? If not, what do I need to change to make it acceptable?
Thanks,
wt
On Sun, Mar 9, 2008 at 1:32 AM, Warren Turkal <[EMAIL PROTECTED]> wrote:
> PosgreSQL hackers,
>
> Here's an initial bit of my
PosgreSQL hackers,
Here's an initial bit of my attempt at cleaning up the the timestamp datatype.
I have gone through the backend and made a couple small changes to stop using
the HAVE_INT64_TIMESTAMP define to select a type in code by creating typedefs
in a header and using the typedef in the cod
I added TimeOffset and DateOffset typedefs to get rid of the instances
using the HAVE_INT64_TIMESTAMP define being used to determine the
types of variables or functions in timestamp.c.
---
src/backend/utils/adt/timestamp.c | 77 +++-
src/include/utils/timestamp.h
I have removed all instances of using HAVE_INT64_TIMESTAMP to determine the
type of a variable in files depending on timestamp.h.
---
src/backend/utils/adt/nabstime.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/src/backend/utils/adt/nabstime.c b/src/backend/utils/
PosgreSQL hackers,
Here's an initial bit of my attempt at cleaning up the the timestamp datatype.
I have gone through the backend and made a couple small changes to stop using
the HAVE_INT64_TIMESTAMP define to select a type in code by creating typedefs
in a header and using the typedef in the cod
I am working on some beginner level patches to help clean up the
timestamp code in PostgreSQL.
Basically, my first few patches are aimed at removing the dependence
on the HAVE_INT_TIMESTAMP to choose types for variables. I will
eventually try to remove the use of HAVE_INT64_TIMESTAMP to choose
pro
This patch is in error. Please ignore. I have already sent the corrected patch.
Thanks,
wt
On Jan 22, 2008 12:50 PM, Warren Turkal <[EMAIL PROTECTED]> wrote:
> I added TimeOffset and DateOffset typedefs to get rid of the instances
> using the HAVE_INT64_TIMESTAMP define being used
I added TimeOffset and DateOffset typedefs to get rid of the instances
using the HAVE_INT64_TIMESTAMP define being used to determine the
types of variables or functions in timestamp.c.
---
src/backend/utils/adt/timestamp.c | 77 +++-
src/include/utils/timestamp.h
Here is a fixed patch for the timestamp refactor. I apologize for sending the
wrong patch earlier.
I would like to get some comments on if this patch is heading in the right
direction. Here's the proposal for what I am doing:
Proposal for Refactoring of Timestamp Datatype
Goal:
The primary go
I added TimeOffset and DateOffset typedefs to get rid of the instances
using the HAVE_INT64_TIMESTAMP define being used to determine the
types of variables or functions in timestamp.c.
---
src/backend/utils/adt/timestamp.c | 77 +++--
src/include/utils/timestamp.h
On Jan 13, 2008 9:21 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Warren Turkal" <[EMAIL PROTECTED]> writes:
> > I have a question. Are the low level representations of Timestamp and
> > TimestampTZ the same?
>
> They're the same but the interpreta
-my gmail account
On Jan 13, 2008 12:13 AM, Warren Turkal <[EMAIL PROTECTED]> wrote:
> On Jan 12, 2008 5:23 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Hmm, PackedTime seems like a fairly random name for the type --- there's
> > not anything particularly "pa
On Jan 12, 2008 5:23 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Hmm, PackedTime seems like a fairly random name for the type --- there's
> not anything particularly "packed" about it IMO.
>
> I'm a bit inclined to suggest just using the Timestamp typedef.
> I guess though that there's some risk of c
On Jan 11, 2008 3:42 PM, Ron Mayer <[EMAIL PROTECTED]> wrote:
> What would be the drawbacks of
> CREATE TABLE tablename(...)
> PARTITION BY function_taking_row_returning_partition_name
> instead of the explicit types?
Would that still allow the optimizer to work as well as it could? It
seems t
On Jan 9, 2008 9:51 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> "Warren Turkal" <[EMAIL PROTECTED]> writes:
> > I was wondering if there is a reason that the flex and bison and other
> > generated source files end up in the source directory when doing an
&
On Jan 9, 2008 10:00 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Really? I think you've confused some unimplemented decorative syntax
> with what the underlying datatype will or won't do.
Fair enough. The underlying type certainly will do it since it works
without the opt_interval.
> > This is inc
On Jan 9, 2008 11:06 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > On Jan 10, 2008 5:00 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> The spec's approach to datetime operations in general is almost totally
> >> brain-dead, ...
>
> > It's true that the spec
On Jan 9, 2008 10:44 PM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> On Jan 10, 2008 5:00 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > The spec's approach to datetime operations in general is almost totally
> > brain-dead, and so you won't find a lot of support around here for hewing
> > to the straig
On Jan 9, 2008 9:29 PM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> Sorry, a correction. The issue of years vs. days isn't ignored. A
> year is just 12 months, which yields 12 * 30 = 360 days, which is
> actually a pretty significant error (1.4% on average).
YEAR TO MONTH and DAY TO {HOUR,MINUTE,S
I was wondering if there is a reason that the flex and bison and other
generated source files end up in the source directory when doing an
out-of-tree build. Would a patch that puts those files in the build
trees be accepted?
wt
---(end of broadcast)---
On Jan 9, 2008 8:33 PM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> I argued in a long-dead thread that we should disallow these kinds of
> comparisons altogether, but I didn't manage to generate much
> enthusiasm. The overall sentiment seemed to be that the slightly
> bogus results were more useful
The year to month and day to second intervals should not overlap. The
standard doesn't actually allow it IIRC.
wt
On Jan 9, 2008 7:17 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Ilya A. Kovalenko" <[EMAIL PROTECTED]> writes:
> > I suggest one more standard date/time operator, to divide one interva
77db4f84999161c0c7ba8ded78636512cc719878 Mon Sep 17 00:00:00 2001
From: Warren Turkal <[EMAIL PROTECTED]>
Date: Wed, 9 Jan 2008 00:19:46 -0800
Subject: [PATCH] Add PackedTime typedef.
The PackedTime type is meant to be a type that holds the hour, minute,
second, and fractional seconds part of th
On Jan 4, 2008 4:20 AM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Perhaps what you want here is to define a type for calculation results
> (double/int64). Whether it is used in the code for minutes or hours is
> irrelevant to the typedef.
Okay...that sounds good. Do you have a good name for it?
On Jan 3, 2008 8:54 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I wrote:
> > Do we really need "fhour_t" and "fminute_t" on top of "fsec_t"?
> > This seems like a bad factorization ...
>
> After some more thought: I think that what's bugging me is that "fsec_t"
> is intended to denote "fractional sec
7e814 Mon Sep 17 00:00:00 2001
From: Warren Turkal <[EMAIL PROTECTED]>
Date: Thu, 3 Jan 2008 19:59:51 -0800
Subject: [PATCH] Add typedefs for hour and minute types.
The HAVE_INT64_TIMESTAMP define was being used to select the types for
the hour and minute field variables. I changed them to us
Is there a reason that the value of the HAVE_INT64_TIMESTAMP macro is
used to choose a datatype in datetime.c instead of having a typedef
defined?
I would like to write a patch to change constructs like the following:
#ifdef HAVE_INT64_TIMESTAMP
int64 span1,
span2;
#else
On Monday 16 July 2007 22:32:07 Shruthi A wrote:
> > > Please reply soon, this is an emergency..
This may be obvious, but a quick reply might call for commercial support.
Check out [1].
[1]http://www.postgresql.org/support/professional_support
wt
--
Warren Tur
ite the Makefiles in any case.
wt
--
Warren Turkal (w00t)
---(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
On Wednesday 11 April 2007 12:24, Andrew Dunstan wrote:
> If we could use configure for MSVC this would have Just Happened (tm). I
> wonder how many other little bits we miss out on?
CMake anyone?
wt
--
Warren Turkal (w00t)
---(end of bro
possible that you are using the SGML
processor to generate the document instead of the XML processor?
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
.postgresql.org::pgsql-cvs /home/cvsmirror/pg
>
> and the exclude file has these four lines:
>
> /sup/
> /CVSROOT/loginfo*
> /CVSROOT/commitinfo*
> /CVSROOT/config*
This setup prunes 1.25MB.
Are you suggesting that I prune this from the conversion?
wt
--
Warren Turkal (w0
.
Everything looks good now. Cvs2svn makes its through where the error
originally occurred.
Joshua, can you see if your conversion script can do a conversion without
deleting the perl5 directory?
wt
--
Warren Turkal (w00t)
---(end of broadcast)-
On Monday 26 February 2007 10:13, Bruce Momjian wrote:
> Warren Turkal wrote:
> > On Saturday 24 February 2007 16:47, Chad Wagner wrote:
> > > head pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle,v
> > > head ? ?1.3;
> > > access;
> > >
for valid time tables
* add support for transaction time tables
* add support for bi-temporal tables
Check out [1] for more info.
[1]http://www.cs.arizona.edu/~rts/
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 9: In versions below 8.0,
t the very least, it could be a
much shorter process than what the current conversion takes (about 3.25 hours
on my laptop). Here's ([1]) another interesting bit.
[1]http://wiki.services.openoffice.org/wiki/SVNMigration
wt
--
Warren Turkal (w00t)
---(end of broadca
On Monday 26 February 2007 10:13, Bruce Momjian wrote:
> Done. Any other problems?
Only figuring out the encoding issues with cvs.
Thanks,
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
(this one is pretty)
* vimdiff
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 6: explain analyze is your friend
newstyle,v
* test.pl.oldstyle,v
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
he $Id$-type keyword lines.
However, I am having a problem with encodings in some of the files. How does
cvs handle files with different encodings? For instance, it looks like the
Chinese documentation gets messed up upon svn conversion.
wt
--
Warren Turkal (w00t)
---(
s it is explicit in the other
systems. To convert to git, for instance, I converted to svn and then
imported that.
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
essages during import except that some commit comments
appear to be in some encoding other than ascii. I am in the middle of
checking commits involving those files to make sure they make sense.
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP
ng makes a lot of sense to me.
This all sounds truly reasonable. I am glad that I could get all your opinions
on the subject. If you do decide to move to anything else in a couple years,
hopefully I can help the process somehow.
Thanks,
wt
--
Warren Turkal (w00t)
---
f a new dev cycle would probably be a
more appropriate time. However, that doesn't mean we can't start thinking
now.
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
.
Thanks,
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
lity to
reap the benefits of the newer SCMS systems.
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
ade to work? I'll even volunteer to set it up.
[1]http://sam.zoy.org/writings/programming/svn2cvs.html
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
re?
> locks; strict;
> comment @# @;
Can a cvs maintainer please correct this file by adding a ";" after the
first "creation" line and removing the second "creation" line?
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 6: explain analyze is your friend
x27;re referring to.
Thanks,
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
On Saturday 24 February 2007 00:24, Warren Turkal wrote:
> The interesting thing about Git is that is has two way sync support for a
> SVN repository also. You could run a Git repository pushing changes in real
> time to a SVN repository and present a CVS frontend also. I would like
think would be a pretty good thing.
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 6: explain analyze is your friend
On Wednesday 21 February 2007 21:23, Warren Turkal wrote:
> Are there any plans to move to another SCMS in the future? I am curious, I
> guess.
Is it possible to obtain a mirror of the CVS repository? The version of CVS on
the repository server is incompatible with cvsps (at least the vers
have looked?
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
eracting with a git
repo. Cogito makes it as simple as anything else I have seen out there.
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [
ms to have been in its new location. For
(1), you can't easily find the history for a file, and for (2), you can't
check out old version and expect them to just work.
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 4: Have you sea
ry also. You could run a Git repository pushing changes in real time
to a SVN repository and present a CVS frontend also. I would like to try
converting the CVS repository of PostgreSQL to Git and try setting some of
this stuff up. Does anyone know how I could get the CVS repository files?
on with minimal
changes. Over time, they could be moved to Git.
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
I can't find a link under
[1].
[1]http://www.postgresql.org/developer/
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
hat.
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
On Wednesday 21 February 2007 21:23, Warren Turkal wrote:
> Are there any plans to move to another SCMS in the future? I am curious, I
> guess.
Speaking of which...Are there any plans to upgrade the CVS server to the
latest version?
wt
--
Warren Turkal (w00t)
-
The cvs gateway server comes with it AFAIK.
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 6: explain analyze is your friend
are others of course
> (like monotone) but most projects I know are moving from cvs to svn or
> starting with svn.
Git is also pretty cool, too. You can even present a CVS interface on a git
repository. That might address the build farm issue.
wt
--
Warren Turkal (w00t)
--
ry anyway, I think.
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
On Thursday 22 February 2007 00:42, you wrote:
> I think you just made my point for me.
I wasn't trying to convince so much as get an opinion.
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 4: Have you searched our list
if
you were to check out new SCMSes? Would you want distributed like Git or
centralized like CVS/Subversion?
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
On Thursday 22 February 2007 00:20, Tom Lane wrote:
> Nobody got round to it. I believe it's listed in the TODO file ...
It's not at [1]. Should someone add it to the TODO?
[1]http://www.postgresql.org/docs/faqs.TODO.html
wt
--
Warren Turkal (w00t)
-
Is there a reason why the DATE type does not support infinity something like
the DATE type?
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Are there any plans to move to another SCMS in the future? I am curious, I
guess.
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
check it out.
[1]http://archives.postgresql.org/pgsql-hackers/2007-02/msg00540.php
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joinin
here is an equality relation on periods. But it wouldn't really tell you much
useful info, as it's not normally what you're looking for with time.
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 9: In versions below 8.0, the pla
On Saturday 17 February 2007 01:50, Hannu Krosing wrote:
> Is tinterval meant to be open/closed at start and end ?
I don't see the tinterval doing anything other than storing two times.
wt
--
Warren Turkal (w00t)
---(end of broadcast)-
On Fri, Feb 16, 2007 at 05:39:24PM -0300, Alvaro Herrera wrote:
> FWIW there's already a type called tinterval that stores (start,end). I
> don't think it's very much documented; maybe it can be extended or used
> as base for a new, more complete and robust type, indexable in a more
> natural way,
Temporal Extensions for PostgreSQL
by: Warren Turkal
I would like to see a comprehensive solution to time varying tables (or
temporal) in PostgreSQL. I specifically want to see suuport for valid-time and
transacation-time and bitemporal (valid-time and transaction-time) tables. I
will be defering
of a conforming
implementation of this data type.
[1]http://www.cs.arizona.edu/~rts/tdbbook.pdf
Thanks,
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
of a conforming
implementation of this data type.
[1]http://www.cs.arizona.edu/~rts/tdbbook.pdf
Thanks,
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail comma
79 matches
Mail list logo