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
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 v
"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 rece
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
> i
"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 :-(
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 acceptab
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
>>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.
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
>>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
> >> 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 a
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 and
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 implementation
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
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
15 matches
Mail list logo
