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 the
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 correct?
2) Would it be reasonable to change timestamp.h into a file that
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 the int64 format the default?
This was gone over in great detail just recently
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 the
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?
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?
It's in the to-do queue for the current commit fest. The queue is kinda
long however :-(
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
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
On Sun, Mar 09, 2008 at 12:32:20AM -0800, Warren Turkal wrote:
1) Is there a reason that header information is duplicated between normal
posgresql include and ecpg includes instead of defining the info in one place
and #including it into the files that need it?
As long as both implementations
Michael Meskes wrote:
On Sun, Mar 09, 2008 at 12:32:20AM -0800, Warren Turkal wrote:
1) Is there a reason that header information is duplicated between normal
posgresql include and ecpg includes instead of defining the info in one place
and #including it into the files that need it?
Merlin
As long as both implementations are kept in sync I don't see a reason.
Sharing the backend data type converters with client stuff is an obvious
win, but its a tedious process probably lacking any motivation. We did
look at it though, it is possible.
I thought we were just talking about
I thought we were just talking about some definitions.
I was expanding on your #1 question, which was directly talking about shared
headers rather than just cleaning out HAVE_INT64_TIMESTAMP. I had the same
experience but also ran into the need for shared library code; which BTW ecpg
could
Michael Meskes [EMAIL PROTECTED] writes:
As long as both implementations are kept in sync I don't see a reason.
Sharing the backend data type converters with client stuff is an obvious
win, but its a tedious process probably lacking any motivation. We did
look at it though, it is
conveniences of the backend coding environment in a frontend application
I don't think this is required. I'm thinking about light-weight wrappers around
A-2-B style converters, no ties to the backend or client. A free standing util
library. The idea doesn't require a backend environment.
15 matches
Mail list logo
