Apparently the signature for function SPI_cursor_open got an additional
"read_only" parameter starting with 8.0.0beta3. The documentation states
that this flag should be "true for read-only execution".
I can't see any mention of this on the hackers list nor in the change logs.
Is it correct to assume that this flag implies that some kind of
optimization has been added and that if this flag is "false", the
execution of the statement will take somewhat longer? I need some advice
in how to handle this.
In PL/Java, I use this method in my JDBC implementation and have little
knowledge of what the intentions are at that point in time since I don't
write the actual code that will use it.
A couple of questions:
Besides from the plain obvious like INSERT, UPDATE, and DELETE, any
SELECT that calls a function may potentially change something right?
What are the implications of setting this flag to false always?
Why doesn't SPI_prepare figure this out with some help from attributes
that defines the characteristics of involved functions? I.e. why isn't
the "read-only" a property of the statement itself rather than something
to be provided when the statement is executed.
Can one single statement be executed in both read-only and not read-only
mode?
Regards,
Thomas Hallgren