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 to deprecate
the float format or at least make
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
types of variables or functions
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. Your two messages of 3/09 are
still the latest version
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 attempt at cleaning up
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, what do I need to change to make it acceptable
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
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
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
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
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
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 +++--
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
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
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 to determine
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 interpretations are different, which is why
I think it's useful to have
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 confusion
-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 packed about it IMO.
I'm a bit inclined
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 that
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 the time
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 interval
by
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 than
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
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
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
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 fails to consider
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
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
out-of-tree build. Would a patch that puts those
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?
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 use a typedef
to make
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 seconds. The other
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;
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 Turkal (w00t
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 broadcast
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
. 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)---
TIP 2: Don't 'kill -9
-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 (w00t)
---(end
,v
* test.pl.oldstyle,v
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
)
* vimdiff
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 6: explain analyze is your friend
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
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 broadcast)---
TIP 3: Have you checked our extensive FAQ
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
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;
symbols
? ? ? ? Release-1-6-0:1.1.1.1
? ? ? ? creation:1.1.1.1
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 1: if posting
, 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
$-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)
---(end
good thing.
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 6: explain analyze is your friend
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 to
try
to.
Thanks,
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
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
? 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
http
.
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
message can get through to the mailing list cleanly
.
Thanks,
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
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
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)
---(end of broadcast
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
[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
, 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
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?
wt
--
Warren Turkal (w00t
), 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 searched our list archives?
http
. 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 [EMAIL PROTECTED] so
--
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.
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 version
is better at disconnected operation than CVS,
so it might be a non-issue for many. Even so, it might be a pity to have
to forego the facility.
Check out svnsync for SVN. It's part of a normal SVN installation.
With git, a checkout brings the whole repository anyway, I think.
wt
--
Warren
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)
---(end of broadcast
with it AFAIK.
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.
Speaking of which...Are there any plans to upgrade the CVS server to the
latest version?
wt
--
Warren Turkal (w00t)
---(end
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
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
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)
---(end of broadcast
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
http
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 archives
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)---
TIP 9
. 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 planner will ignore your desire to
choose an index scan
://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 joining column's datatypes do
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 command
79 matches
Mail list logo
