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
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 |
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 |