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


---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings

Reply via email to