Re: Thoughs after discussions at OSCON - Mailing list pgsql-advocacy

jnasby@pervasive.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
attribute.

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',
'Ruby', 'Tcl', 'PHP', 'JavaScript'), where the result would be a set
of functions in those respective languages.

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
them.

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 :-).
--
output = reverse("moc.enworbbc" "@" "enworbbc")
http://www3.sympatico.ca/cbbrowne/linuxdistributions.html
"Implying that you    can build systems  without  rigourous  interface
specification is always a powerful selling technique to the clueless."
-- Paul Campbell, seen in comp.object.corba