Chris Browne wrote:
> jnasby(at)pervasive(dot)com ("Jim C. Nasby") writes:
>>So far, the best solution I've seen is the XML-based 'datadef' that
>>a friend of mine created at a former job. It was database-centric
>>enough so that it could drive the entire database creation process
>>(including triggers, stored procs, etc) and do it well, while also
>>creating application code (C/C++ in this case). Since it was
>>XML/XSLT based it was pretty easy to add new features, and more
>>importantly, it could support any programming language out
>>there. Everything else I've seen is tied to a specific language,
>>which is a big downside. Unfortunately, he never wanted to release
>>it to the community because he felt the implementation was ugly.
> I don't much like that; that adds a layer that can fall out of date,
> and offers NOTHING in terms of tools to get things resynchronized.
> What would be the "nice to have" thing is some system that allows you
> to extract a set of field validation functions from the database.
> In effect, you do:
> select a.attname, field_validation_function(c.oid, a.attname, 'Perl')
> from pg_class c, pg_attribute a where a.attrelid = c.oid and c.relname
> = 'my_table');
> which returns a list of Perl 'validation functions', one for each
> Each validation function would take data passed in, validate it
> against some Perl-encoded form of the DBMS constraints, and either:
> a) Return 0/NULL, indicating that all is OK, or
> b) Return a matrix of error messages indicating the failures
> It would be neat (would it not? :-)) to allow passing in other names
> of languages, e.g. where scripting_language in ('Perl', 'Python',
> of functions in those respective languages.
Yes! That's exactly the kind of concept I was looking for.
> It would probably be ideal for what is to be returned to be, in each
> case, the local equivalent to a lambda function so that it could be
> transparently embedded inside the user's favorite application
> framework rather than forcing some Procrustean naming convention on
AFAIK each of these has some analogue to the lambda function--even PHP
with create_function(): www.php.net/create_function.
Another 'nice to have' would be a way to provide methods to extract a
value from each column datatype into a suitable variable in the
scripting language. That would be very nice for date columns, arrays, etc...
> If the result was some hunk of XML that could be automatically
> transformed into suitable lambda functions, that's OK too, although
> there is the demerit that it FORCES a further rewriting process.
> I'm not sure what to do about multicolumn constraints, but that's
> probably troublesome even in theory :-).
In response to
pgsql-advocacy by date
|Next:||From: Robert Treat||Date: 2005-08-16 19:05:39|
|Subject: Re: Publishing and PostgreSQL|
|Previous:||From: Chris Browne||Date: 2005-08-16 16:50:24|
|Subject: Re: Thoughs after discussions at OSCON|