Signature change for SPI_cursor_open

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