On 3-Aug-06, at 3:59 PM, Tom Lane wrote:
> Dave Cramer <pg@fastcrypt.com> writes:
>> However I'm still puzzled by these backend logs
>
>> <test test>LOG: statement: PREPARE S_3 AS INSERT INTO texttable (te)
>> VALUES ($1)
>> <test test>LOG: statement: <BIND>
>> <test test>LOG: statement: EXECUTE <unnamed> [PREPARE: INSERT INTO
>> texttable (te) VALUES ($1)]
>
>> We see the prepare to a named statement, but then the execute is
>> unnamed ?
>
> What it's showing you there is the name of the protocol-level portal;
> evidently you're using the unnamed portal to execute the INSERT.
If that's the case then the driver is not doing what it's supposed to
be doing. It should be using the named portal (S_3) to do the insert.
Dave
>
> This does demonstrate once again that the current approach to logging
> parse/bind/execute operations is entirely wrongheaded, because it
> deliberately confuses the protocol and SQL levels. I see that Bruce
> has changed CVS tip so that the message is
>
> <test test>LOG: statement: [protocol] EXECUTE <unnamed>
> [PREPARE: INSERT INTO
> texttable (te) VALUES ($1)]
>
> but I hardly think that's going to be enough to de-confuse people.
> All those brackets just serve to make things *more* confusing IMHO.
>
> What I'd like to see is something like this:
>
> Simple Query produces
>
> LOG: statement: ...statement text here...
>
> Parse produces
>
> LOG: parse statement-name: ...statement text here...
>
> Bind produces
>
> LOG: bind portal-name to statement-name (someday print arguments
> here)
>
> Execute produces
>
> LOG: execute portal-name: ...statement text here...
>
> No brackets, no pretending that an Execute message is the same thing
> as a SQL EXECUTE command or that Parse is the same as PREPARE.
>
> regards, tom lane
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>
