Re: Converting Postgres SQL constraint logic to PHP?

On Fri, 2016-06-10 at 13:01 -0700, Ken Tanzer wrote:
> Hi.  I was hoping this list might be able to offer some
> help/advice/suggestions/opinions about feasibility for something I
> want to implement, namely converting Postgres constraints into PHP
> logic.  Here's the context and explanation:
>
> I work on a PHP web app using Postgres.  When possible, we try to
> build as much logic as possible directly into the DB.  The app
> already automatically reads NOT NULL and foreign key constraints from
> the DB, and enforces them through the UI thus preventing people from
> getting ugly database errors.  It doesn't do that with check
> constraints and table constraints though, which means we either end
> up duplicating the constraint logic in PHP, or else sometimes get
> lazy/expedient and only put the constraint into PHP.  Obviously
> neither of those is ideal.
>
> What would be ideal is for the app to handle those constraints
> automatically.  It looks like I can pull them out (as SQL) from
> information_schema.check_constraints, with the remaining issue being
> how to make them usable in PHP.
>
> I'm wondering if anyone has done this already, or if there is some
> kind of library available for this purpose?
>
> If not, and absent any better suggestions, I'm looking at trying to
> parse/search/replace.  This might well be imperfect, and error-
> prone.  But if I can get something that at least works in a lot of
> cases, that would help a lot.  So as a simple example, converting
> from
>
> ((sat3 >= 0) AND (sat3 <= 5))
>
> to the needed format:
>
> (($rec['sat3'] >=0) and ($rec['sat3'] <= 5))
>
> seems like it would be relatively straightforward, since the
> structure of the logic is neatly parallel between SQL and PHP.  Each
> of these below, and many others I could pull, all have additional
> complications beyond that though:
>  (((incentive_sent_date IS NULL) OR (incentive_sent_date >=
> residence_date)))
> (((application_date IS NOT NULL) OR (employment_date IS NOT NULL)))
>  (xor((assessed_by IS NULL), (assessor_organization IS NULL)))
>  (((release_to IS NULL) OR ((consent_type_code)::text = ANY
> ((ARRAY['ROI'::character varying, 'MEDIA'::character
> varying])::text[]))))
> So anyway, there's my issue.  Any thoughts/comments/suggestions
> welcome.  Thanks in advance!
>
> Ken
>
>
Hi Ken,

Would this be static or dynamic?
For example, if you altered a column to become defined as NOT NULL,
say, when you build the form used to maintain that table you'd like to
have a "required" attribute against the input field for that column. So
if it were dynamic you'd have to access the database information_schema
each time you wanted to send the HTML down the wire as well as when
carrying out validation.
Also, views are updateable and you'd have to check the tables and
columns making up the view.
I've never used pg_meta_data but it might be helpful.
Another thought would be to write a program that scanned all the tables
in your database and wrote out a table in your application's schema
where the table and column constraints were synthesised in a way
suitable for use in PHP code. 

Cheers,
Rob