> Tom Lane wrote:
>
> > > It is now fixed in the attached patch.
> >
> > Applied with some additional cleanup (the code wasn't multibyte-aware,
> > and so could get fooled in some Far Eastern encodings).
Looking at your cleanup is a good for learning more about C. :-)
But I have one another que
Tom Lane wrote:
> > It is now fixed in the attached patch.
>
> Applied with some additional cleanup (the code wasn't multibyte-aware,
> and so could get fooled in some Far Eastern encodings).
I am very pleased to hear. This was my first patch submitted. :-)
Best Regards,
Michael Paesold
--
"Michael Paesold" <[EMAIL PROTECTED]> writes:
>> Per SQL spec, the backend thinks that /* .. */ nests:
> It is now fixed in the attached patch.
Applied with some additional cleanup (the code wasn't multibyte-aware,
and so could get fooled in some Far Eastern encodings).
> Concerning my other pat
Michael Paesold wrote
> Tom Lane wrote:
> > Per SQL spec, the backend thinks that /* .. */ nests:
> >
> > regression=# /* some /* comment */ comment */ select 1;
> > ?column?
> > --
> > 1
> > (1 row)
> >
> > As it stands, is_transact_command will get confused by this.
It is now fi
Tom Lane wrote:
> "Michael Paesold" <[EMAIL PROTECTED]> writes:
> > Or do I not understand what you mean by nested
> > comments? (There is code for ignore /* .. */ before the first keyword.)
>
> Per SQL spec, the backend thinks that /* .. */ nests:
>
> regression=# /* some /* comment */ comment *
"Michael Paesold" <[EMAIL PROTECTED]> writes:
> Or do I not understand what you mean by nested
> comments? (There is code for ignore /* .. */ before the first keyword.)
Per SQL spec, the backend thinks that /* .. */ nests:
regression=# /* some /* comment */ comment */ select 1;
?column?
---
Tom Lane wrote:
> If we're going to do that, we should also include the other statements
> that disallow execution in a transaction, and we should rename
> is_transact_command to something more appropriate (not to mention fix
> its comments). A quick grep shows
>
> PreventTransactionChain((void
"Michael Paesold" <[EMAIL PROTECTED]> writes:
> In current cvs (as in version 7.4.5), VACUUM does not work at all in
> autocommit=off mode. That is, because psql does not know that VACUUM cannot
> be performed inside an transaction.
> I consider this a bug and suggest the attached fix.
If we're go
In current cvs (as in version 7.4.5), VACUUM does not work at all in
autocommit=off mode. That is, because psql does not know that VACUUM cannot
be performed inside an transaction.
Even if you do
ROLLBACK; VACUUM;
it will internally issue a ROLLBACK; BEGIN; VACUUM;
I consider this a bug and sugge
