From: | Andrew Chernow <ac(at)esilo(dot)com> |
---|---|
To: | Warren Turkal <turkal(at)google(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: timestamp datatype cleanup |
Date: | 2008-03-09 14:48:44 |
Message-ID: | 47D3F8CC.9010907@esilo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 I ran into this question while working on the libpq type system,
found here:
http://archives.postgresql.org/pgsql-patches/2008-03/msg00057.php
It opens up the binary parameterized interface in libpq by providing data type
converters, to and from external binary format and C data types, when performing
queries or getting results. This required copying and pasting some code from
the backend for a couple types ... like datetime and numeric. We had to work
around several backend compile-time checks by using run-time checks; being how
servers are compiled differently.
The most modular approach would be to abstract the backend/utils/adt API so the
backend and client stuff can share the functionality. We did mention this
during one of our patch submissions, but didn't push it as it is a large change
outside the scope of our patch.
>> 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.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Dawid Kuroczko | 2008-03-09 17:55:44 | Re: Idea: Comments on system catalogs? |
Previous Message | Michał Zaborowski | 2008-03-09 14:16:58 | Lazy constraints / defaults |