Suggestions please: names for function cachability 
Author Message
 Suggestions please: names for function cachability

Quote:

> BTW, because of MVCC semantics, case 2 covers more ground than you might
> think.  We are interested in functions whose values cannot change during
> a single "scan", ie, while the intra-transaction command counter does
> not increment.  So functions that do SELECTs are actually guaranteed to
> be case 2, even if stuff outside the function is changing the table
> being looked at.

> My problem is picking names for the three categories of functions.
> Currently we use "with (isCachable)" to identify category 1, but it
> seems like this name might actually be more sensible for category 2.
> I'm having a hard time picking simple names that convey these meanings
> accurately, or even with a reasonable amount of suggestiveness.

> Comments, ideas?

How about:

case 1: Cachable
case 2: ScanCachable or Optimizable
case 3: NonCachable

Joe

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.***.com/



Sun, 19 Sep 2004 05:57:34 GMT
 Suggestions please: names for function cachability

Quote:
Tom Lane writes:
> Since I'm about to have to edit pg_proc.h to add a namespace column,
> I thought this would be a good time to revise the current proiscachable
> column into the three-way cachability distinction we've discussed
> before.  But I need some names for the values, and I'm not satisfied
> with the ideas I've had so far.

Well, for one thing, we might want to change the name to the correct
spelling "cacheable".

Quote:
> 1. Strictly cachable (a/k/a constant-foldable): given fixed input
> values, the same result value will always be produced, for ever and
> ever, amen.  Examples: addition operator, sin(x).  Given a call
> of such a function with all-constant input values, the system is
> entitled to fold the function call to a constant on sight.

deterministic

(That's how SQL99 calls it.)

Quote:
> 2. Cachable within a single command: given fixed input values, the
> result will not change if the function were to be repeatedly evaluated
> within a single SQL command; but the result could change over time.
> Examples: now(); datetime-related operations that depend on the current
> timezone (or other SET-able variables); any function that looks in
> database tables to determine its result.

"cacheable" seems OK for this.

Quote:
> 3. Totally non-cachable: result may change from one call to the next,
> even within a single SQL command.  Examples: nextval(), random(),
> timeofday().  (Yes, timeofday() and now() are in different categories.
> See http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/functions...)

not deterministic, not cacheable

--

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly



Sun, 19 Sep 2004 08:56:05 GMT
 Suggestions please: names for function cachability

Quote:

> Tom Lane writes:

> > Since I'm about to have to edit pg_proc.h to add a namespace column,
> > I thought this would be a good time to revise the current proiscachable
> > column into the three-way cachability distinction we've discussed
> > before.  But I need some names for the values, and I'm not satisfied
> > with the ideas I've had so far.

> Well, for one thing, we might want to change the name to the correct
> spelling "cacheable".

> > 1. Strictly cachable (a/k/a constant-foldable): given fixed input
> > values, the same result value will always be produced, for ever and
> > ever, amen.  Examples: addition operator, sin(x).  Given a call
> > of such a function with all-constant input values, the system is
> > entitled to fold the function call to a constant on sight.

> deterministic

> (That's how SQL99 calls it.)

> > 2. Cachable within a single command: given fixed input values, the
> > result will not change if the function were to be repeatedly evaluated
> > within a single SQL command; but the result could change over time.
> > Examples: now(); datetime-related operations that depend on the current
> > timezone (or other SET-able variables); any function that looks in
> > database tables to determine its result.

> "cacheable" seems OK for this.

SQL99 suggests that there are only two types of user defined
routines: deterministic and 'possibly non-deterministic'. However, in
section 11.49 it defines

<deterministic characteristic> ::= DETERMINISTIC | NOT DETERMINISTIC

So the real problem is how to qualify this.

TRANSACTIONAL DETERMINISTIC

or

NOT DETERMINISTIC CACHEABLE

are the only ways that come to mind. I'll admit that I don't like either.

Quote:

> > 3. Totally non-cachable: result may change from one call to the next,
> > even within a single SQL command.  Examples: nextval(), random(),
> > timeofday().  (Yes, timeofday() and now() are in different categories.
> > See http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/functions...)

> not deterministic, not cacheable

Gavin

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Sun, 19 Sep 2004 09:47:53 GMT
 Suggestions please: names for function cachability

Quote:

> Well, for one thing, we might want to change the name to the correct
> spelling "cacheable".

Is that correct?

I looked in the Oxford English Dictionary, the Random House Dictionary,
and a couple other dictionaries of less substantial heft, and could not
find anything authoritative at all.  RH gives the derived forms "cached"
and "caching"; OED offers nothing.  I'd be interested to see an
authoritative reference for the spelling of the adjective form.

Possibly we should avoid the issue by using another word ;-)

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster



Sun, 19 Sep 2004 12:42:20 GMT
 Suggestions please: names for function cachability
On Tue, 02 Apr 2002 23:39:35 -0500

Quote:


> > Well, for one thing, we might want to change the name to the correct
> > spelling "cacheable".

> Is that correct?

Apparently, other people are confused as well:

        http://www.xent.com/FoRK-archive/august97/0431.html

FWIW, google has ~30,000 results for -eable, and ~8,000 results for
-able. A couple other software projects (notably Apache Jakarta)
use -eable.

My preference would be for -eable, but that's just on the basis of
"it looks right", which is hardly authoritative.

Cheers,

Neil

--

PGP Key ID: DB3C29FC

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly



Sun, 19 Sep 2004 12:55:17 GMT
 Suggestions please: names for function cachability

Quote:
> FWIW, all the blacklists I use (and 510sg is only the first line of
> defense ;-)) have documentation available about the reasons for listing
> IP blocks.  F'r instance, looking up Thomas' IP I get:
...
> But this is getting pretty far off-topic for the PG lists.

I'll guess that the list of reasons for the blacklisting I find today is
different than the list I found a few months ago when this first came
up. What is relevant to me is that I absolutely cannot get my machine
removed from this blacklist, no matter what I do to secure that machine.
And that, istm, reduces the relevance of that particular blacklisting
strategy.

I was just using this as an example (I happen to send mail directly to
you so have run across it in this context).

I'm interested because spam has affected me in other contexts too, and
every time it takes time away from PostgreSQL.

We could sent up Yet Another List, say pgsql-spam-whiners, and I could
be a charter member, and maybe y'all would suggest I should also be on
pgsql-clueless-spam-whiners. But maybe it is better to have an
occasional discussion on topics that people find affecting their use of
the mailing list(s) ;)

I have to say that spam is bumming me out more now than it ever has in
the past. So let's hope that the blacklists *do* help somehow!

                    - Thomas

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Mon, 20 Sep 2004 06:27:51 GMT
 
 [ 6 post ] 

 Relevant Pages 

1. Suggestions please: names for function cachability attributes

2. Suggestions please: names for function

3. Suggestions please: names for function cachabilityattributes

4. Suggestions please: names for function cachabilityattributes

5. HELP: ODBC function to return database name and path from DataSoure Name

6. Suggestion for aggregate function

7. Suggestion for aggregate function

8. Suggestions on moving databases to new server with same name

9. Suggestions for naming conventions

10. VMark/Unidata Name Suggestions

11. Slow connections over Named Pipes net-lib ... suggestions

12. Looking for suggestions for styleguide SQL programming and naming conventions


 
Powered by phpBB® Forum Software