On mån, 2010-03-01 at 16:29 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > SQL standard:
>
> > ::=
> > 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 is that CONTAINS SQL allow
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
Tom Lane wrote:
> Peter Eisentraut writes:
>> SQL standard:
>
>> ::=
>> 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 n
On Mon, Mar 1, 2010 at 4:29 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> SQL standard:
>
>> ::=
>> 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 t
Jaime Casanova írta:
> On Mon, Mar 1, 2010 at 2:56 PM, Peter Eisentraut wrote:
>
>> On tis, 2010-02-23 at 16:54 -0500, Jaime Casanova wrote:
>>
>>> On Tue, Feb 23, 2010 at 2:02 PM, Tom Lane wrote:
>>>
There may be some value in inventing a "has no side effects" marker, but
>>>
Peter Eisentraut writes:
> SQL standard:
> ::=
> 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 next-to-last one if you're prepared t
On Mon, Mar 1, 2010 at 2:56 PM, Peter Eisentraut wrote:
> On tis, 2010-02-23 at 16:54 -0500, Jaime Casanova wrote:
>> On Tue, Feb 23, 2010 at 2:02 PM, Tom Lane wrote:
>> >
>> > There may be some value in inventing a "has no side effects" marker, but
>> > that should not be confused with IMMUTABLE
On tis, 2010-02-23 at 16:54 -0500, Jaime Casanova wrote:
> On Tue, Feb 23, 2010 at 2:02 PM, Tom Lane 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:
::=
NO
On Tue, Feb 23, 2010 at 10:18 PM, Tom Lane 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 parsing and all of
Tatsuo Ishii 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 whether the funct
> 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
> > 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 al
Simon Riggs 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
--
Sent via pgsql-hack
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
On Mon, 2010-02-22 at 23:49 -0500, Tom Lane wrote:
> Tatsuo Ishii 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
On Tue, Feb 23, 2010 at 2:02 PM, Tom Lane 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 desarrollo de
Greg Stark wrote:
> Kevin Grittner 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 facilitate jury selection. My eyes are o
On Tue, Feb 23, 2010 at 2:02 PM, Tom Lane 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 (pgsql-hackers@postgresql.
Greg Stark writes:
> On Tue, Feb 23, 2010 at 6:39 PM, Kevin Grittner
> 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 is about
how long the function value
On Tue, Feb 23, 2010 at 6:39 PM, Kevin Grittner
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 stable. Ok, for that one I
Greg Stark wrote:
> Kevin Grittner 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 timestamp without timezone functions (which
On Tue, Feb 23, 2010 at 4:52 PM, Kevin Grittner
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 non-volatile function to
Tom Lane wrote:
> "Kevin Grittner" 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 error, but I can't
think of anywhere
On Tue, Feb 23, 2010 at 11:08 AM, Tom Lane 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 could be...
> A
> > 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 q
"Kevin Grittner" writes:
> Tom Lane 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 th
Tom Lane 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 fu
> > 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 al
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 sen
Tatsuo Ishii 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 classificat
"Tatsuo Ishii" 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
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,
32 matches
Mail list logo
