Lists: | pgsql-interfaces |
---|
From: | tomas(at)aura(dot)de |
---|---|
To: | averstak(at)vt(dot)edu (Alex Verstak) |
Cc: | pgsql-interfaces(at)postgreSQL(dot)org |
Subject: | Re: [INTERFACES] Type mappings |
Date: | 100-03-07 16:29:39 |
Message-ID: | 200003071629.RAA09163@ns.aura.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-interfaces |
>
> tomas(at)aura(dot)de wrote:
[...]
> Types don't change too often. Not often enough to hurt the
> UI's anyway, which is what JDBC is for. On the other hand,
> speed gain from caching type information is significant.
>
Ummm... I wasn't implying not to cache the types -- I think
caching is a must. But we could (for example) invalidate the
cache whenever anything happens to the pg_types table (that
would imply setting up a notifier (did I get the PostggreSQL
parlance right?)
> > It would be interesting to write up a type mapper which could be
> > of some more general utility (no idea whether this would be
> > feasible at all). I'd be willing to give it a try.
>
> It is a useful thing. E.g. my project needs conversion between
> SDDF, SQL, (restricted form of) Prolog, and Jess (don't ask
> why--it's a long story). I would definitely appreciate a
> generic type mapper. It is feasible too. My chicken scratch
> has worked so far. :)
>
The question is... what do we use as the target data types? I
could just go for the Guile data types -- but then we have
Just Another Type Mapper, Not Useful To Anyone (TM). Maybe
with a bit more of thought (say you can register conversion
functions with it, depending on the PostgreSQL type name (but
it might make sense to base our decisions on other attributes
of the table, like the input/output functions)) we could
get something more useful.
> JDBC source has the queries you need. PostgreSQL manual
> decribes the types. It's just a matter of sitting down
> and writing a pretty wrapper/converter.
>
Thanks, I'm already having a look at it. It's very readable.
regards
-- tomas
From: | "Alex Verstak" <averstak(at)vt(dot)edu> |
---|---|
To: | pgsql-interfaces(at)postgreSQL(dot)org |
Subject: | Re: [INTERFACES] Type mappings |
Date: | 2000-03-07 15:19:42 |
Message-ID: | 200003071519.KAA60856@averstak.campus.vt.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-interfaces |
tomas(at)aura(dot)de wrote:
> Obe of the things squile tries is to transform the database
> types into native language types.
>
> For PostgreSQL this would imply looking things up in the
> pg_types table and figuring out what to do.
...
> - jdbc looks the type name (via the oid, as given by PQftype())
> and decides based on that. The result is cached (which to me
> looks a bit problematic, since the contents of the table could
> change at run time, but I may be too pedantic here ;)
Types don't change too often. Not often enough to hurt the
UI's anyway, which is what JDBC is for. On the other hand,
speed gain from caching type information is significant.
> It would be interesting to write up a type mapper which could be
> of some more general utility (no idea whether this would be
> feasible at all). I'd be willing to give it a try.
It is a useful thing. E.g. my project needs conversion between
SDDF, SQL, (restricted form of) Prolog, and Jess (don't ask
why--it's a long story). I would definitely appreciate a
generic type mapper. It is feasible too. My chicken scratch
has worked so far. :)
> I would appreciate any pointers in this directions.
JDBC source has the queries you need. PostgreSQL manual
decribes the types. It's just a matter of sitting down
and writing a pretty wrapper/converter.
=alex