The proposed patch implements TRUNCATE ... CASCADE:
* %Allow TRUNCATE ... CASCADE/RESTRICT
This is like DELETE CASCADE, but truncates.
The patch also adds a function makeRangeVarFromRelId() to namespace.c that I
thought would be useful. I hope I didn't overlook something similar that
exists
Joachim Wieland wrote:
The proposed patch implements TRUNCATE ... CASCADE:
* %Allow TRUNCATE ... CASCADE/RESTRICT
This is like DELETE CASCADE, but truncates.
The patch also adds a function makeRangeVarFromRelId() to namespace.c that I
thought would be useful. I hope I didn't overlook
Andrew Dunstan [EMAIL PROTECTED] writes:
As a matter of curiosity, why does ecpg handle dollar quoting like that?
psql, for example, happily just passes a dollar quoted string through to
the backend, without any need to convert it to a conventionally quoted
string.
Doesn't ecpg have to
On Thu, 2006-02-02 at 16:41 -0500, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
As a matter of curiosity, why does ecpg handle dollar quoting like that?
psql, for example, happily just passes a dollar quoted string through to
the backend, without any need to convert it to a
* Tom Lane ([EMAIL PROTECTED]) wrote:
I agree. I wonder if it wouldn't be cleaner to pass the information in
the other direction, ie, send a boolean down to PrintTocData saying you
are sending SQL commands or you are sending COPY data. Then, instead
of depending only on the libpq state to
Andrew Dunstan wrote:
On Wed, 2006-02-01 at 23:48 -0500, Bruce Momjian wrote:
I have researched your report, and you are right, there are two ecpg
bugs here. First, dollar quoting uses single-quotes internally to do
the quoting, but it does not double any single-quotes in the
Here is an updated patch. It fixes things in the places it should be
fixed by handling \n at the time we double-quote, and double single
quotes at the place we are building the $$ string.
I am going to apply this to HEAD. It is a fix, but I am worried it
might affect ecpg users who might have
