Luke Lonergan wrote: > Bruce, > > > 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 > <ctl-byte><any-byte>...mblen...<any-byte> > > 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@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend