Skip site navigation (1) Skip section navigation (2)

Re: Thoughs after discussions at OSCON

From: Rick Morris <rick(at)brainscraps(dot)com>
To: pgsql-advocacy(at)postgresql(dot)org
Subject: Re: Thoughs after discussions at OSCON
Date: 2005-08-16 19:01:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-advocacy
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
> 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.

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

AFAIK each of these has some analogue to the lambda function--even PHP 
with 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 TreatDate: 2005-08-16 19:05:39
Subject: Re: Publishing and PostgreSQL
Previous:From: Chris BrowneDate: 2005-08-16 16:50:24
Subject: Re: Thoughs after discussions at OSCON

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group