Re: db encoding - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: db encoding
Date
Msg-id 3F81ADDC.4080005@dunslane.net
Whole thread Raw
In response to Re: db encoding  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: db encoding
List pgsql-hackers
Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: db encoding
Next
From: "monu_indian"
Date:
Subject: index changing