Prev: [HACKERS] synchronous commit in dump
Next: More robust pg_hba.conf parsing/error logging
From: Takahiro Itagaki on 22 Feb 2010 23:15

"Tatsuo Ishii" <ishii(a)postgresql.org> wrote:

> VOLATILE functions such as random() and timeofday() apparently do not
> write and sending those queries that include such functions is
> overkill.

> Can we VOLATILE property divide into two categories, say, VOLATILE
> without write, and VOLATILE with write?

I think it's possible. We might borrow words and semantics from
unctional programming languages for functions with side effects.
How do they handle the issue?

BTW, random() *writes* the random seed, though no one will mind it.

Regards,
---
Takahiro Itagaki
NTT Open Source Software Center



--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 22 Feb 2010 23:49
Tatsuo Ishii <ishii(a)postgresql.org> writes:
> I'm wondering if we could detect a funcion has a side effect,
> i.e. does a write to database.

> Currently we have three properties of functions: IMMUTABLE, STABLE and
> VOLATILE. According to docs IMMUTABLE or STABLE functions do not write
> to database.

Those classifications are meant as planner directives; they are NOT
meant to be bulletproof. Hanging database integrity guarantees on
whether a "non volatile" function changes anything is entirely unsafe.
To give just one illustration of the problems, a nonvolatile function
is allowed to call a volatile one.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Alvaro Herrera on 23 Feb 2010 09:44
Tatsuo Ishii wrote:
> Hi,
>
> I'm wondering if we could detect a funcion has a side effect,
> i.e. does a write to database. This is neccessary for pgpool to decide
> if a qeury should to be sent to all of databases or not. If a query
> includes functions which do writes to database, it should send the
> query to all of databases, otherwise the contents of databases go into
> inconsistent state.

I was talking about this to someone in Cuba and one conclusion we
reached was that this was a fairly difficult task -- consider that
someone may choose to define an innocent-looking operator using a
volatile function. If you only examine things that look like functions
in the query you will miss those. The only way to figure out whether a
query has a write effect is to ask the server about the whole query.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tatsuo Ishii on 23 Feb 2010 10:05
> > I'm wondering if we could detect a funcion has a side effect,
> > i.e. does a write to database. This is neccessary for pgpool to decide
> > if a qeury should to be sent to all of databases or not. If a query
> > includes functions which do writes to database, it should send the
> > query to all of databases, otherwise the contents of databases go into
> > inconsistent state.
>
> I was talking about this to someone in Cuba and one conclusion we
> reached was that this was a fairly difficult task -- consider that
> someone may choose to define an innocent-looking operator using a
> volatile function. If you only examine things that look like functions
> in the query you will miss those. The only way to figure out whether a
> query has a write effect is to ask the server about the whole query.

In general you are right. However in most database application
systems, it is possible that all functions are properly designed and
implemented (at least they want so). In this world, more or less
PostgreSQL functions are just a part of their applications. If they
trust their client side applications, why they cannot trust PostgreSQL
custom functions as well?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: "Kevin Grittner" on 23 Feb 2010 10:40
Tom Lane <tgl(a)sss.pgh.pa.us> wrote:

> Those classifications are meant as planner directives; they are
> NOT meant to be bulletproof. Hanging database integrity
> guarantees on whether a "non volatile" function changes anything
> is entirely unsafe. To give just one illustration of the
> problems, a nonvolatile function is allowed to call a volatile
> one.

Could it work to store a flag in each process to indicate when it is
executing a non-volatile function, and throw an error on any attempt
to call a volatile function or modify the database?

-Kevin

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Prev: [HACKERS] synchronous commit in dump
Next: More robust pg_hba.conf parsing/error logging