[PATCHES] CONNECT BY for 8.3 ...
good morning everybody,this is a working version of evgen potemkin's patch implementing CONNECT BY. it has been ported to 8.3 and it seems to work flawlessly with CVS head.it is not supposed to be included into 8.4 but i guess it might be useful for some people.there are still some limitations and design issues along with Oracle specific syntax.however, it can be very useful for special purpose applications as it is ways faster than connectby(). many thanks and best regards, hans hier-Pg8.3.tgz Description: Binary data --Cybertec Schönig Schönig GmbHPostgreSQL Solutions and SupportGröhrmühlgasse 26, 2700 Wiener NeustadtTel: +43/1/205 10 35 / 340www.postgresql.at, www.cybertec.at
[PATCHES] Fix ecpg SQL CONNECT with variable user name
Here is a fix for ecpg in 8.3 when the user name is specified by
variables on SQL CONNECT.
When we compile the following statement in ecpg:
EXEC SQL CONNECT TO :dbname USER :usrname IDENTIFIED BY :usrpass;
ecpg in 8.2 compiles it correctly.
{ ECPGconnect(__LINE__, 0, dbname , usrname , usrpass , NULL, 0); }
but ecpg in 8.3beta4 returns wrong results.
{ ECPGconnect(__LINE__, 0, dbname , $1 , $2 , NULL, 0); }
It seems to come from the change of create_questionmarks() in
http://archives.postgresql.org/pgsql-committers/2007-08/msg00185.php
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/preproc/preproc.y?r1=1.348r2=1.349
Variables are represented as $%d instead of ? now.
The grammer of user_name should have followed the change.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
ecpg-connect.patch
Description: Binary data
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [PATCHES] [HACKERS] Unworkable column delimiter characters for COPY
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think at minimum we need to forbid b, f, n, r, t, v, which are the
control character representations currently recognized by COPY.
But I'm tempted to make it reject all 26 lower-case ASCII letters,
as a form of future-proofing. Thoughts?
Assuming this is only for non-CSV mode, it seems OK.
On looking closer, 'x', octal digits, and '.' would also be trouble.
So I made it reject a-z, 0-9, and dot.
It appears that the CSV mode is a few bricks shy of a load here as
well: it will let you do CSV DELIMITER '' resulting in entirely
broken output. It seems we ought to forbid delimiter from matching CSV
quote or escape characters. I'll let you clean up that case though...
This should do the trick - I'll apply it tomorrow.
cheers
andrew
Index: copy.c
===
RCS file: /cvsroot/pgsql/src/backend/commands/copy.c,v
retrieving revision 1.293
diff -c -r1.293 copy.c
*** copy.c 27 Dec 2007 18:28:58 - 1.293
--- copy.c 28 Dec 2007 04:07:06 -
***
*** 889,894
--- 889,907
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg(COPY delimiter cannot be
\%s\, cstate-delim)));
+ /* In CSV mode, disallow quote or escape chars as delimiter */
+ if (cstate-csv_mode)
+ {
+ if (cstate-delim[0] == cstate-quote[0])
+ ereport(ERROR,
+
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+errmsg(COPY delimiter and
quote must be different)));
+ else if (cstate-delim[0] == cstate-escape[0])
+ ereport(ERROR,
+
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+errmsg(COPY delimiter and
escape must be different)));
+ }
+
/* Check header */
if (!cstate-csv_mode cstate-header_line)
ereport(ERROR,
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [PATCHES] [HACKERS] Unworkable column delimiter characters for COPY
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: It seems we ought to forbid delimiter from matching CSV quote or escape characters. I'll let you clean up that case though... This should do the trick - I'll apply it tomorrow. A couple thoughts: * This test needs to appear further down --- it is not sensible until after you've checked strlen() == 1 for all the strings involved. * I see that we disallow the CSV quote character from appearing in the null_print string, but not the escape character. Is this correct/sensible? If it is correct, maybe the delimiter could also match the escape character? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
