Re: Deprecating RULES

On Mon, Oct 15, 2012 at 02:14:34PM +0100, Peter Geoghegan wrote:
> On 15 October 2012 00:30, Greg Stark <stark(at)mit(dot)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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +