ecpg stuff

Joking aside, there is one bug or better missing feature that I need some
input on. Does anyone know what the standards say to the prepare command? Is
dynamic SQL a standard?

Yes it is. I have the Date/Darwen book on the SQL standard, and can look up
answers in the book if you like...

- Tom

Thomas G. Lockhart writes:

Joking aside, there is one bug or better missing feature that I need some
input on. Does anyone know what the standards say to the prepare command? Is
dynamic SQL a standard?

Yes it is. I have the Date/Darwen book on the SQL standard, and can look up
answers in the book if you like...

Yes, I like that. Could you please also lookup:

- the whenever statement
- and check resp. tell me whether the cursor behaviour is correct. Currently
the declare statement is send to the backend via PQexec. The open statement
is ignored and the fetch is executed as fetch via PQexec. I think the data
shouldn't be processed before the cursor is opened. But I do not know
what PostgreSQL does with the declare command.

Michael

--
Dr. Michael Meskes, Project-Manager | topsystem Systemhaus GmbH
meskes@topsystem.de | Europark A2, Adenauerstr. 20
meskes@debian.org | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10

Or we should change the declare/open behaviour in that it ignores the
embedded SQL declare command and just sends the declare command when it
finds an open. But then standard may say that the actual way is correct.

Michael

--
Dr. Michael Meskes, Project-Manager | topsystem Systemhaus GmbH
meskes@topsystem.de | Europark A2, Adenauerstr. 20
meskes@debian.org | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10

Michael Meskes wrote:

- and check resp. tell me whether the cursor behaviour is correct. Currently
the declare statement is send to the backend via PQexec. The open statement
is ignored and the fetch is executed as fetch via PQexec. I think the data
shouldn't be processed before the cursor is opened. But I do not know
what PostgreSQL does with the declare command.

DECLARE: parser + optimizer + ExecutorStart (initializes plan nodes:
checks permissions, opens tables & indices).
Is OPEN statement in standard ?
If yes then we could call ExecutorStart() for the OPEN someday.

Vadim

Meskes, Michael wrote:

Or we should change the declare/open behaviour in that it ignores the
embedded SQL declare command and just sends the declare command when it
finds an open. But then standard may say that the actual way is correct.

It seems that OPEN is in standard and this is really bad that we havn't
OPEN statement: using DECLARE we could plan query once and then
re-use this plan many times - OPEN, FETCH-es, CLOSE; OPEN, ...
Also, we could use queries with parameters (like in SQL-funcs: $1, ...)
in DECLARE and then assign parameter' values in OPEN and execute
cursor for different values.
Isn't this what Oracle allow ?

Vadim

Meskes, Michael wrote:

Or we should change the declare/open behaviour in that it ignores the
embedded SQL declare command and just sends the declare command when it
finds an open. But then standard may say that the actual way is correct.

It seems that OPEN is in standard and this is really bad that we havn't
OPEN statement: using DECLARE we could plan query once and then
re-use this plan many times - OPEN, FETCH-es, CLOSE; OPEN, ...
Also, we could use queries with parameters (like in SQL-funcs: $1, ...)
in DECLARE and then assign parameter' values in OPEN and execute
cursor for different values.
Isn't this what Oracle allow ?

Yes, I agree we should have it, and allow cursors outside transactions
with OPEN/CLOSE behavior.

Added to TODO.

--
Bruce Momjian
maillist@candle.pha.pa.us