On Wed, 23 Dec 2009 11:36:31 -0500
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Craig Ringer <craig@postnewspapers.com.au> writes:
> > Pavel Stehule wrote:
> >> these queries are executed in some special mode, but still it
> >> is more expensive than C a = a + 1
>
> > ... and may have different rules, so you can't just write a
> > simple "map expressions to C equivalents" arithmetic evaluator.
> Yeah. As an example, overflow is supposed to be caught in "a + 1",
> unlike what would happen in C.
> In principle you could map some of the builtin operators into
> inline code, but it would be a great deal of work and the results
> would be un-portable.
Tank you all for being so patient...
I really miss how actually procedural languages works internally.
doesn't pg routinely map between SQL and C?
What is the difference between
select a+a from data;
and
a := a + a;
in a plpgsql function?
plpgsql knows that a are eg. int so it could just use the same C
code that it uses when it has to sum a+a in sql.
My guess since I don't even know what to look for to get an idea of
the internal working of plpgsql is that the interpreter translate
the code into SQL (sort of...), it sends it to the parser through
SPI_execute/prepare etc... (so yeah maybe for the "data" it is not
really sending "text" representation of data) but still... the
"code" has to be further interpreted...
So something like:
a := a + a;
turns out to be:
SPI_prepare("SELECT $1 + $2", 2, ...);
and this is going to be called for every loop.
while I thought the SQL engine and plpgsql interpreter were nearer
so that the interpreter could push directly in the SQL engine the
values of a.
Am I getting nearer?
--
Ivan Sergio Borgonovo
http://www.webthatworks.it