Re: encoding names

Karel Zak writes:

>  New names is possible obtain only by:
>
>      database_character_set()
>         - returns database encoding name
>
>      character_set(int)
>         - convert encoding 'id' to encoding name
>
>      character_set(name)
>         - convert encoding 'name' to 'id'

I thought we decided not to add functions returning "new" names until we
know exactly what the new names should be, and pending schema
implementation.  These three functions just implement an interface that is
equivalent to an existing one but no more standard than the existing one.

> l2=# select getdatabaseencoding(), database_character_set();
>  getdatabaseencoding | database_character_set
> ---------------------+------------------------
>  LATIN2              | ISO-8859-2
> (1 row)

For instance, from an SQL point of view, the left side is more official
than the right side, and it's easier to handle as identifier.

> l2=# select pg_encoding_to_char(5), character_set(5);
>  pg_encoding_to_char | character_set
> ---------------------+---------------
>  UNICODE             | UTF-8
> (1 row)

Spelled UTF8 in SQL.  This is a boring debate, but it needs to be done
first, so people can rely on the names.  Accepting flexible input is good,
but the output needs to be reliable.


Also:

    pg_char_to_encname_struct(): too much long encoding name

better

    ...(): encoding name too long

The rest looks okay superficially, but someone else should probably check
it.

--
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter