| From: | Chris Travers <chris(at)metatrontech(dot)com> | 
|---|---|
| To: | Listmail <lists(at)peufeu(dot)com> | 
| Cc: | Stuart Cooper <stuart(dot)cooper(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> | 
| Subject: | Re: The rule question before, request official documentation on the problem | 
| Date: | 2007-04-11 16:21:46 | 
| Message-ID: | 461D0B1A.6030407@metatrontech.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general | 
Listmail wrote:
<snip>
>
>
>     Since we now have UPDATE/INSERT/DELETE RETURNING, one could 
> imagine the rules using these to access the actual rows and not the 
> expressions...
>
>     But there is a perfectly valid argument against that :
>
>     - There already is a mechanism designed specifically for this 
> purpose (triggers).
>     - It works perfectly.
>     - Rules are supposed to rewrite queries to do stuff like views.
Agreed.
I have narrowed the problem cases down to a subset I think should be 
mentioned in the docs.
DO ALSO rules involving NEW are fundamentally dangerous to the integrity 
of data because NEW is not guaranteed to be internally consistent.  DO 
INSTEAD rules are fine (there is only one NEW), as are any DO ALSO rules 
involving OLD.
We already protect against programmers using unsafe and non-standard 
quote escapes.  I have sent in my cases to a number of other people, 
some of which are deeply involved in PostgreSQL development, and the 
initial behavior was not properly predicted by any of them.  This is why 
I say that if this is the defined behavior of rules, that a clear and 
obvious warning needs to be placed in the docs that this is dangerous 
and in every case I can think of, not something you want to use a rule for.
Imagine, for example, that we have an application that is built.  Uses 
DO ALSO rules with NEW to replicate user-supplied data from one table to 
an audit trail or the like,  Everything works fine until someone decides 
to load up a database with random data.  The programmer did not foresee 
this and put his trust in PostgreSQL's features for data integrity.  
Given the comments I found in the docs, I suspect that people *are* 
using DO ALSO rules frequently when these are dangerous.  Since this can 
cause problems based on user-supplied input, this is a problem.
One of the things that causes me to favor PostgreSQL for all my projects 
is the strong emphasis on data integrity by the community, perhaps 
better than any other RDBMS out there.  Being unwilling to warn clearly 
and loudly about unsafe features does undermine that commitment.
>
>     It should be mentioned in the docs, though : someone with an 
> account on the PG site should copypaste this mail exchange in the 
> comments field...
>
For 90% of what I do, I use the local copy of the docs.  My concern is 
that (at least in 8.1) there is no obvious warning about DO ALSO rules 
using NEW to be inherently nondeterministic.   I checked the online 8.2 
docs and while there was the bit about the expression substitution, 
there still was not a warning about this behavior being fundamentally 
nondeterministic.  I would like to see a note in the section comparing 
triggers to rules explaining that this subset of rules is not deterministic.
Best Wishes,
Chris Travers
| Attachment | Content-Type | Size | 
|---|---|---|
| chris.vcf | text/x-vcard | 181 bytes | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Listmail | 2007-04-11 16:49:18 | Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version | 
| Previous Message | Andrew Edson | 2007-04-11 16:21:33 | Select taking excessively long; Request help streamlining. |