Re: generic modelling of data models; enforcing constraints dynamically...
От | Sam Mason |
---|---|
Тема | Re: generic modelling of data models; enforcing constraints dynamically... |
Дата | |
Msg-id | 20090924202523.GJ22438@samason.me.uk обсуждение исходный текст |
Ответ на | Re: generic modelling of data models; enforcing constraints dynamically... (Rob Marjot <rob@marjot-multisoft.com>) |
Ответы |
Re: generic modelling of data models; enforcing constraints
dynamically...
|
Список | pgsql-general |
On Thu, Sep 24, 2009 at 09:23:35PM +0200, Rob Marjot wrote: > SELECT doesComply('relationname', keyValues.*) FROM (VALUES('col1', > CAST(col1 AS TEXT)), VALUES('col2', CAST(col2 AS TEXT))) AS > keyValues(the_key, the_value); > > The function "doesComply()" will then process the CONSTRAINTS table and > raise an Error if the new / updated row does not fit... I'd have a set of doesComply functions, the first two parameters as you have them but overload a set to support different datatypes specifically. Something like: CREATE FUNCTION doesComply(_rel TEXT, _key TEXT, _val INT) ... CREATE FUNCTION doesComply(_rel TEXT, _key TEXT, _val DATE) ... CREATE FUNCTION doesComply(_rel TEXT, _key TEXT, _val TEXT) ... CREATE FUNCTION doesComply(_rel TEXT, _key TEXT, _val NUMERIC) ... And then have a set of "attribute" tables (one for each datatype) to store the actual values in. At least PG can do some type checking for you that way. Either that, or just leave them all as text to text mappings in the database and only attempt to type things out in the client code. Not sure why you're doing the VALUES contortions as well, why not just: SELECT doesComply('relationname', 'col1', col2); ? -- Sam http://samason.me.uk/
В списке pgsql-general по дате отправления: