Luke Lonergan wrote:
> > We have two and three-byte encodings, so 16-bit seems like it wouldn't
> > work. I am not aware of any specs except the C code itself.
> Ok - no problem.
> How about test data and cases? I see the SQL encoding examples used in
> src/test/regress/sql for testing encoding in SQL, but are there regressions
> for QA/test of multi-byte encoding support? If not, that's OK, but it would
> save us time if some were already written.
No, I don't think so, but the good news is that the existing code has
always worked flawlessly.
> WRT the COPY command, I'd like to have regressions that test the input of
> matched client/server encodings with different (standardized) multi-byte
> control characters.
Makes sense, but how do we know what encodings the client supports? We
would need some tests for that.
> The current code seems to allow for an arbitrary second byte in control
> characters, so if we made a statement about control character support, I
> think it would be
> is allowed for specification of control characters (newline, delimiter).
I have no idea what you are talking about. Again, give me facts about
what we currently don't do and what you want to do.
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
In response to
pgsql-hackers by date
|Next:||From: Simon Riggs||Date: 2005-06-03 22:06:49|
|Subject: WAL bypass for CTAS|
|Previous:||From: Luke Lonergan||Date: 2005-06-03 21:31:04|
|Subject: Re: NOLOGGING option, or ?|