Re: Add ENCODING option to COPY
От | Hitoshi Harada |
---|---|
Тема | Re: Add ENCODING option to COPY |
Дата | |
Msg-id | AANLkTim+xAyEb5QffifpdV=modwpUNc28zWM6DX7sTSw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add ENCODING option to COPY (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Add ENCODING option to COPY
|
Список | pgsql-hackers |
2011/2/5 Tom Lane <tgl@sss.pgh.pa.us>: > Hitoshi Harada <umi.tanuki@gmail.com> writes: >> 2011/2/5 Tom Lane <tgl@sss.pgh.pa.us>: >>> The reason that we use quotes in CREATE DATABASE is that encoding names >>> aren't assumed to be valid SQL identifiers. If this patch isn't >>> following the CREATE DATABASE precedent, it's the patch that's wrong, >>> not CREATE DATABASE. > >> What about SET client_encoding TO encoding? > > SET is in its own little world --- it will interchangeably take names > with or without quotes. It is not a precedent to follow elsewhere. I see. I'll update my patch, after the mb change discussion gets done. >> * Can we use #ifndef FRONTEND in the header? >> Usage of fmgr.h members will broke client applications without the #ifdef, >> but I guess client apps don't always have definitions of FRONTEND. >> If we don't want to change pg_wchar.h, pg_conversion_fn.h might be >> a better header for the new API because FindDefaultConversion() is in it. > > Yeah, putting backend-only stuff into that header is a nonstarter. Do you mean you think it' all right to define pg_cached_encoding_conversion() in pg_conversion_fn.h? Regards, -- Hitoshi Harada
В списке pgsql-hackers по дате отправления: