pg.ddx.io pgsql-interfaces@postgresql.org mailing list archivehelp / color / mirror / Atom feed
Re: [INTERFACES] Type mappings 3+ messages / 2 participants [nested] [flat]
* Re: [INTERFACES] Type mappings @ 2000-03-07 15:19 Alex Verstak <averstak@vt.edu> 0 siblings, 0 replies; 3+ messages in thread From: Alex Verstak @ 2000-03-07 15:19 UTC (permalink / raw) To: pgsql-interfaces tomas@aura.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 ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: [INTERFACES] Type mappings @ 2000-03-07 20:28 Alex Verstak <averstak@vt.edu> 0 siblings, 0 replies; 3+ messages in thread From: Alex Verstak @ 2000-03-07 20:28 UTC (permalink / raw) To: pgsql-interfaces tomas@aura.de wrote: > 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?) Yes, that's a nice solution. I don't need it right now, so I don't really care. ;) > > > 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. You might get some ideas from SDDF: http://www-pablo.cs.uiuc.edu/Project/SDDF/SDDFOverview.htm I think, type name alone is sufficient, but users should be able to specify their own conversion functions. For example, a table: create table foo (bar1 text, bar2 int4); insert into foo values ('one', 1); insert into foo values ('two', 2); might be translated into Prolog as: % foo(+string, +integer) foo('one', 1). foo('two', 2). However, this is not the only way (and often not the best way) to do the conversion. What's best should be decided by the user. All *I* am looking for is a neat wrapper around all those selects that fills in some parse-tree-like structures. I am not particularly picky about types, but I would like the thing to run in the database backend, as opposed to another process (huge performance advantage in my case). I would prefer it to be in Tcl, or, failing that, in C. Basically, I need to select a subset of data from a bunch of tables and convert it for use by other tools, e.g. for a data mining or a production system; and convert their output back to SQL. It is just one example of how a generic type mapper might be used. Your goals might be totally different. =alex ^ permalink raw reply [nested|flat] 3+ messages in thread
* RE: [INTERFACES] Type mappings @ 2000-03-09 07:57 Peter Mount <petermount@it.maidstone.gov.uk> 0 siblings, 0 replies; 3+ messages in thread From: Peter Mount @ 2000-03-09 07:57 UTC (permalink / raw) To: 'Alex Verstak' <averstak@vt.edu>; pgsql-interfaces As usual when replying from here, replies prefixed with PM: -- Peter Mount Enterprise Support Maidstone Borough Council Any views stated are my own, and not those of Maidstone Borough Council. -----Original Message----- From: Alex Verstak [mailto:averstak@vt.edu] Sent: Tuesday, March 07, 2000 3:20 PM To: pgsql-interfaces@postgreSQL.org Subject: Re: [INTERFACES] Type mappings tomas@aura.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. PM: Which is what JDBC does. It reads the information only when it first needs to, then caches it in a Hashtable. > 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. PM: Most of the JDBC queries came from the psql source :-) ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2000-03-09 07:57 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2000-03-07 15:19 Re: [INTERFACES] Type mappings Alex Verstak <averstak@vt.edu> 2000-03-07 20:28 Re: [INTERFACES] Type mappings Alex Verstak <averstak@vt.edu> 2000-03-09 07:57 RE: [INTERFACES] Type mappings Peter Mount <petermount@it.maidstone.gov.uk>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox