Re: db encoding

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Postgresql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: db encoding
Date: 2003-10-06 18:01:00
Message-ID: 3F81ADDC.4080005@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-hackers-win32

Tom Lane wrote:

>Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>
>>However, from an initdb POV I am assuming that we are only interested in
>>the name=>number conversion, even though initdb.sh does no apparent
>>checking on the parameter it is passing to pg_encoding. Please tell me
>>if this is incorrect.
>>
>>
>
>That's correct. I believe we intended to eliminate pg_encoding as a
>separate program altogether, given a C version of initdb, since the C
>code could perfectly well call pg_char_to_encoding and
>pg_valid_server_encoding for itself.
>
>
>
Yes, but when I asked that question at least one voice piped up (Debian
package maintainer, I think) to say that these were still needed as
standalone programs. However, I have already replaced the calls I
previously had to these from the C version (pg_id a few days ago,
pg_encoding a few minutes ago ;-) ) There will be a new C version on my
web site tonight, including inline calls to
pg_char_to_encoding()/pg_valid_server_encoding and signal handling
(these are actually the only 2 things we need libpq for).

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message monu_indian 2003-10-06 18:19:19 index changing
Previous Message Tom Lane 2003-10-06 17:47:55 Re: db encoding

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Peter Eisentraut 2003-10-06 18:30:47 Re: db encoding
Previous Message Tom Lane 2003-10-06 17:47:55 Re: db encoding