On 2014-09-06 6:06 PM, Jan Wieck wrote:
You can dismiss what we're doing by saying that it doesn't follow the
best practices or we just want an interface for a key-value store or
whatever. And yes, to some extent, a simple interface for a key-value
store would come in handy. But we still have the 5-15% (big part of it
being the reporting we need to do) of the code that *doesn't* want that,
*and* we want to use all of the Postgres features where applicable.
The point isn't about best practices.
It got to that point upthread.
The point is that if you want to
ensure that at maximum one row is affected, then qualify it by a unique
set of columns.
And what if you get the set of columns wrong (also consider the presence
of joins)? What if someone changes that set of columns? What if your
unique indexes have been violated because of a bug in postgres or
hardware malfunction? Wouldn't you want the problem to be obvious?
Making PL/pgSQL behave different on UPDATE than SQL to
enforce that by default was simply a misguided design idea.
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*.
.marko
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
