You da man Bernard! I've been wanting to do this for a while also, but
hadn't taken the time to puzzle through it.
> In fact istm that the correct way to handle now() would be to have a
> value that is constant over a transation, and comensurate with the
> numbering of tids.
That is the current behavior of now(); Postgres has a time function
which returns the time of the current transaction and now() (and every
other form of date/time 'now') uses that.
When doing this pre-evaluation in the parse tree, is it possible that
the transaction time is not yet set? So perhaps 'now' and now() would
have problems here. Remember that "datetime 'now'" also resembles a
constant but has the same behavior as "now()", so can't really be
considered a true constant either.
> I don't think that random() is a problem at all. It gets called once
> each time it is written in the query string. That is certainly a
> reasonable interpretation of its meaning.
If we use the "is cachable" flag for procedures (*and* for constants
on types!) then it would be possible to have random() behave as
expected- returning unique values for every invocation and unique
values into each field of a single-line query/insert.
I hope we haven't put you off here, and I'd suggest that we
incorporate your patches as they stand now, then work on the next step
later (assuming that it isn't something you have time or interest
for). But if you can see doing this next step already, we'd love to
have it included in the first patch. What do you think?
Thanks for the work. This is a neat area to get improvements for...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California