On Sat, Sep 6, 2014 at 12:38 PM, Jan Wieck-3 [via PostgreSQL] <[hidden email]> wrote:
On 09/06/2014 12:33 PM, Marko Tiikkaja wrote:
> On 2014-09-06 6:31 PM, Jan Wieck wrote: >> On 09/06/2014 12:17 PM, Marko Tiikkaja wrote: >>> OK, fine. But that's not what I suggested on the wiki page, and is also >>> not what I'm arguing for here right now. What the message you referred >>> to was about was the condescending attitude where we were told to "think >>> in terms of sets" (paraphrased), without considering whether that's even >>> possible to do *all the time*. >> >> SQL is, by definition, a set oriented language. The name Procedural >> Language / pgSQL was supposed to suggest that this language adds some >> procedural elements to the PostgreSQL database. I never intended to >> create a 100% procedural language. It was from the very beginning, 16 >> years ago, intended to keep the set orientation when it comes to DML >> statements inside of functions. >> >> No matter how hard you >> try to make them special, in my mind they are not. > > Of course they are. That's why you have PRIMARY KEYs and UNIQUE > constraints.
Then please use those features instead of crippling the language.
If the language, and the system as a whole, was only used by perfectionists that do not make errors - and with perfectly clean data - this adherence to purity would be acceptable. But the real world is not that clean and so enhancing the language to meet the needs of the real world is not crippling the language. Begin able to state explicitly that the cardinality of the set I get back must be 1, no more and no less, doesn't remove the fact that I know I am dealing with a set and that I simply want to make an assertion as to its properties so that if a bug 3 layers deep into the application causes something other than 1 row to be affected I know immediately and can invoke the appropriate action - throw an error.
