On mån, 2010-03-01 at 15:30 -0500, Jaime Casanova wrote:
so IMMUTABLE = DETERMINISTIC NO SQL,
STABLE = DETERMINISTIC READS SQL DATA
VOLATILE = NOT DETERMINISTIC MODIFIES SQL DATA
It might be tempting to create such a mapping, but there could be a
number of pitfalls, especially if you define it
On mån, 2010-03-01 at 16:29 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
SQL standard:
SQL-data access indication ::=
NO SQL
| CONTAINS SQL
| READS SQL DATA
| MODIFIES SQL DATA
Huh. I understand three of those, but what is the use of CONTAINS SQL?
My reading
On tis, 2010-02-23 at 16:54 -0500, Jaime Casanova wrote:
On Tue, Feb 23, 2010 at 2:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
There may be some value in inventing a has no side effects marker, but
that should not be confused with IMMUTABLE/STABLE.
a READONLY function?
SQL standard:
On Mon, Mar 1, 2010 at 2:56 PM, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2010-02-23 at 16:54 -0500, Jaime Casanova wrote:
On Tue, Feb 23, 2010 at 2:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
There may be some value in inventing a has no side effects marker, but
that should not be
Peter Eisentraut pete...@gmx.net writes:
SQL standard:
SQL-data access indication ::=
NO SQL
| CONTAINS SQL
| READS SQL DATA
| MODIFIES SQL DATA
Huh. I understand three of those, but what is the use of CONTAINS SQL?
Seems like that would have to be the same as the last one, or maybe
the
Jaime Casanova írta:
On Mon, Mar 1, 2010 at 2:56 PM, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2010-02-23 at 16:54 -0500, Jaime Casanova wrote:
On Tue, Feb 23, 2010 at 2:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
There may be some value in inventing a has no side effects
On Mon, Mar 1, 2010 at 4:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
SQL standard:
SQL-data access indication ::=
NO SQL
| CONTAINS SQL
| READS SQL DATA
| MODIFIES SQL DATA
Huh. I understand three of those, but what is the use of CONTAINS SQL?
Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
SQL standard:
SQL-data access indication ::=
NO SQL
| CONTAINS SQL
| READS SQL DATA
| MODIFIES SQL DATA
Huh. I understand three of those, but what is the use of CONTAINS
SQL? Seems like that would have to be
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
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
Tom Lane t...@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
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@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
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
On Tue, Feb 23, 2010 at 11:08 AM, Tom Lane t...@sss.pgh.pa.us wrote:
It's *not an error* for a nonvolatile function to call a volatile one.
it should be considered an error i think, someone think there is a use
cas for calling volatile functions
inside stable ones but i can see what that reason
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
throw an error on any attempt to call a volatile function or
modify the database?
It's *not an error* for a nonvolatile function to call a volatile
one.
Right, we all know it currently doesn't throw an
On Tue, Feb 23, 2010 at 4:52 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Right, we all know it currently doesn't throw an error, but I can't
think of anywhere I'd like to have someone do that in a database for
which I have any responsibility. Does anyone have a sane use case
for a
Greg Stark gsst...@mit.edu wrote:
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Does anyone have a sane use case for a non-volatile function to
call a volatile one or to update the database?
So consider for example a function which explicitly sets the
timezone and then uses
On Tue, Feb 23, 2010 at 6:39 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Or somebody who uses the tsearch functions because they're
planning to not change their dictionaries.
I didn't realize tsearch functions were volatile. Should they
really be so?
Uhm, my mistake. They're
Greg Stark gsst...@mit.edu writes:
On Tue, Feb 23, 2010 at 6:39 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
I didn't realize tsearch functions were volatile. Should they
really be so?
Uhm, my mistake. They're stable.
IMMUTABLE/STABLE/VOLATILE is not really about side effects, it
On Tue, Feb 23, 2010 at 2:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
There may be some value in inventing a has no side effects marker, but
that should not be confused with IMMUTABLE/STABLE.
Yeah, that's what I was thinking, too
...Robert
--
Sent via pgsql-hackers mailing list
Greg Stark gsst...@mit.edu wrote:
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Thanks for the examples. They did make me consider a real-life
type of process which isn't currently implemented as a PostgreSQL
function, but conceivably could be -- randomizing a pool of
jurors to
On Tue, Feb 23, 2010 at 2:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
There may be some value in inventing a has no side effects marker, but
that should not be confused with IMMUTABLE/STABLE.
a READONLY function?
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y
On Mon, 2010-02-22 at 23:49 -0500, Tom Lane wrote:
Tatsuo Ishii is...@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
On Tue, 2010-02-23 at 12:51 +0900, Tatsuo Ishii wrote:
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
Simon Riggs si...@2ndquadrant.com writes:
So wrongly marking a function as something other than volatile *is* a
data integrity issue. Why is that OK? ISTM that this should work the way
Tatsuo wants it to work.
Please read the rest of the thread.
regards, tom lane
--
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
IMMUTABLE/STABLE/VOLATILE is not really about side effects, it is about
how long the function value can be expected to hold still for.
There are quite a lot of cases of functions that are marked
conservatively as stable (or even volatile) but could be considered
immutable in particular
Tatsuo Ishii is...@postgresql.org writes:
Apparently IMMUTABLE/STABLE should not write to database according to
docs. Are you saying that in the real world these are ignored? If so,
this is an important database intergrity issue as Simon pointed out.
One more time: these markings are not about
On Tue, Feb 23, 2010 at 10:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Personally I find that goal rather suspect anyway.
I think the chances of determining this reliably in pgpool are
negligible, even if functions were marked like that. You would need to
duplicate *all* of the backend's
Tatsuo Ishii is...@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.
30 matches
Mail list logo
