Обсуждение: Re: [PATCHES] encoding names
Tatsuo Ishii writes: > > But getdbencoding isn't semantically different from the old > > getdatabaseencoding. "encoding" isn't the right term anyway, methinks, it > > should be "character set". So maybe database_character_set()? (No "get" > > please.) > > I'm not a native English speaker, so please feel free to choose more > appropriate name. > > BTW, what's wrong with "encoding"? I don't think, for example EUC-JP > or utf-8, are character set names. Hmm, SQL talks of character sets, it has a CHARACTER_SETS view and such. It's slightly incorrect, I agree. Maybe we should not touch getdatabaseencoding() right now, given that the names we currently use are apparently almost correct anyway and considering the pain it creates to alter them, and instead implement the information schema views in the future? -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
> > BTW, what's wrong with "encoding"? I don't think, for example EUC-JP > > or utf-8, are character set names. > > Hmm, SQL talks of character sets, it has a CHARACTER_SETS view and such. > It's slightly incorrect, I agree. > > Maybe we should not touch getdatabaseencoding() right now, given that the > names we currently use are apparently almost correct anyway and > considering the pain it creates to alter them, and instead implement the > information schema views in the future? I thought schema stuffs would be introduced in 7.2 but apparently it would not happen... -- Tatsuo Ishii
> > > BTW, what's wrong with "encoding"? I don't think, for example EUC-JP > > > or utf-8, are character set names. > > > > Hmm, SQL talks of character sets, it has a CHARACTER_SETS view and such. > > It's slightly incorrect, I agree. > > > > Maybe we should not touch getdatabaseencoding() right now, given that the > > names we currently use are apparently almost correct anyway and > > considering the pain it creates to alter them, and instead implement the > > information schema views in the future? > > I thought schema stuffs would be introduced in 7.2 but apparently it > would not happen... I thought I could do it but ran out of time. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Tatsuo Ishii writes: > > Maybe we should not touch getdatabaseencoding() right now, given that the > > names we currently use are apparently almost correct anyway and > > considering the pain it creates to alter them, and instead implement the > > information schema views in the future? > > I thought schema stuffs would be introduced in 7.2 but apparently it > would not happen... True, but right now we'd have to do rather elaborate changes just to switch a couple of names to "more correct" versions. Accepting them as input is good, but maybe we should hold back on the output part a bit until we can do it correctly. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
> > I thought schema stuffs would be introduced in 7.2 but apparently it > > would not happen... > > True, but right now we'd have to do rather elaborate changes just to > switch a couple of names to "more correct" versions. Accepting them as > input is good, but maybe we should hold back on the output part a bit > until we can do it correctly. Agreed. -- Tatsuo Ishii
On Fri, Aug 24, 2001 at 09:29:06PM +0200, Peter Eisentraut wrote:
> Tatsuo Ishii writes:
>
> > > Maybe we should not touch getdatabaseencoding() right now, given that the
> > > names we currently use are apparently almost correct anyway and
> > > considering the pain it creates to alter them, and instead implement the
> > > information schema views in the future?
> >
> > I thought schema stuffs would be introduced in 7.2 but apparently it
> > would not happen...
>
> True, but right now we'd have to do rather elaborate changes just to
> switch a couple of names to "more correct" versions. Accepting them as
> input is good, but maybe we should hold back on the output part a bit
> until we can do it correctly.
Change output is a very easy work (edit strings in one array). The
important thing is clean internal code for encoding names to faster
and non-duplicated code (use same code for FE and BE).
Well, I prepare it with total back compatible output for all current
routines (pg_char_to_encoding too) and new names will visible by new
routines only (suggested database_character_set(), etc). Right?
Karel
-- Karel Zak <zakkr@zf.jcu.cz>http://home.zf.jcu.cz/~zakkr/C, PostgreSQL, PHP, WWW, http://docs.linux.cz,
http://mape.jcu.cz