From: Alex Verstak <averstak@vt.edu>
To: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] Type mappings
Date: Tue, 07 Mar 2000 15:28:15 -0500
Message-ID: <200003072028.PAA61157@averstak.campus.vt.edu> (raw)
In-Reply-To: <200003071629.RAA09163@ns.aura.de>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: averstak@vt.edu
Subject: Re: [INTERFACES] Type mappings
In-Reply-To: <200003072028.PAA61157@averstak.campus.vt.edu>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
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