On Mon, Oct 15, 2012 at 02:14:34PM +0100, Peter Geoghegan wrote: > On 15 October 2012 00:30, Greg Stark <st...@mit.edu> wrote: > > In fact it's not a very good analogy because the situation is > > *precisely* the same -- rules *are* macros and manipulate the raw sql > > before it's run and the reason they can't be replaced by triggers is > > because, like functions, triggers happen after the code is compiled > > and run. > > I quite like this analogy, because it nicely illustrates the problems > with rules. > > C, and the C preprocessor, are essential the same now as they were in > the early 1970s. I think that *an emphasis* on a preprocessing stage > of translation is a fairly discredited idea (though there are some > sensible uses, particularly where alternatives are not available). C99 > introduced inline functions, probably in no small part because it is > quite obvious that they are often superior to macros. Consider the two > most successful programming languages that were obviously influenced > by C: Java and C++. The first doesn't have a preprocessor, and the > second strongly encourages using numerous alternatives to macros where > possible, which is almost always. Maybe you don't like this analogy, > because you consider C to be a systems programming language, and as > such think it is only right and proper that programmers should be > given enough rope to hang themselves. Perhaps you're right, but the > same surely cannot be said for SQL. The original appeal of SQL was > that it was supposedly possible for non-programmers to write it.
Ah, so Peter confered the Java angle, and I think he does present the pitfalls of C macros, and that does translate to the pitfalls of rules. I have trouble seeing how we could implement Postgres as efficiently without C macros, but maybe that is the point --- efficiency is not critical in SQL --- Java and C++ give other options that are "good enough" and less error-prone. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
