| From: | Andrew Chernow <ac(at)esilo(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Michael Meskes <meskes(at)postgresql(dot)org>, Warren Turkal <turkal(at)google(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: timestamp datatype cleanup |
| Date: | 2008-03-10 01:04:19 |
| Message-ID: | 47D48913.1000705@esilo.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>>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.
>>want to tighten up the expectations on backend datatypes to try
>>to make them work in a frontend-ish environment.
Making timestamp2tm or tm2timestamp (for example) work in the backend as well as
the client seems rather straight forward, unless I am missing something. I am
not talking about making the data type functional: like add, divide, multiply
funtions. I am only referring to data type converters.
>>The chances of that happening reliably are about nil.
Why? Again, I could be missing something.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory Stark | 2008-03-10 01:40:22 | Re: pg_dump additional options for performance |
| Previous Message | Tom Lane | 2008-03-10 00:02:57 | Re: timestamp datatype cleanup |