Andrew Dunstan <[EMAIL PROTECTED]> writes: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).
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.
cheers
andrew
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
