Re: [PATCHES] [HACKERS] UTF8 or Unicode
Further to my earlier e-mail, there would have to be two lines added to
conversion_create.sql for each alternate function name
Like:
CREATE OR REPLACE FUNCTION ascii_to_whatever (INTEGER, INTEGER, CSTRING,
CSTRING, INTEGER) RETURNS VOID AS '$libdir/ascmic', 'ascii_to_mic'
LANGUAGE 'c' STRICT;
CREATE CONVERSION pg_catalog.ascii_to_whatever FOR 'SQL_ASCII' TO
'MULE_INTERNAL' FROM ascii_to_whatever;
Lorne
In <[EMAIL PROTECTED]>, on 02/26/05
at 03:50 PM, Bruce Momjian said:
>Peter Eisentraut wrote:
>> Am Freitag, 25. Februar 2005 05:51 schrieb Bruce Momjian:
>> > so I see what he is saying. We are not consistent in favoring the
>> > official names vs. the common names.
>> >
>> > I will work on a patch that people can review and test.
>>
>> I think this is what we should do:
>>
>> UNICODE => UTF8
>> ALT => WIN866
>> WIN => WIN1251
>> TCVN => WIN1258
>>
>> That should clear it up.
>OK, here is a patch that makes those changes.
>The only uncertainty I have is with the the use of the TCVN conversion
>routine names, e.g.:
> SELECT CONVERT('foo' USING tcvn_to_utf_8);
>I assume this is the same as:
> SELECT CONVERT('foo', 'WIN1258', 'UTF8');
>and
> SELECT CONVERT('foo', 'TCVN', 'UTF8'); -- alias usage
>So, why would people use the routine name? Both forms are documented.
>The first one with USING does not accept aliases, while the others do.
>I think this should be renamed to win1258_to_utf_8. However, this would
>be an incompatibility. We should mention it in the release notes.
>Other than that the other conversion files were already named fine, e.g.
>ascii_to_utf_8 (no UNICODE), however it is utf_8 and not utf8. I am
>unsure how to handle these.
--
---
[EMAIL PROTECTED]
---
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] UTF8 or Unicode
[EMAIL PROTECTED] wrote: > Further to my earlier e-mail, there would have to be two lines added to > conversion_create.sql for each alternate function name > > Like: > > CREATE OR REPLACE FUNCTION ascii_to_whatever (INTEGER, INTEGER, CSTRING, > CSTRING, INTEGER) RETURNS VOID AS '$libdir/ascmic', 'ascii_to_mic' > LANGUAGE 'c' STRICT; > > CREATE CONVERSION pg_catalog.ascii_to_whatever FOR 'SQL_ASCII' TO > 'MULE_INTERNAL' FROM ascii_to_whatever; I would like to avoid bloating the system with aliases. I think it is OK to have it happen with specific names but doing it for all the combinations is too much, and these duplicates are in the system tables, not in the C code. It just doesn't seem worth it to me. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] [HACKERS] UTF8 or Unicode
In <[EMAIL PROTECTED]>, on 02/26/05 at 07:55 PM, Bruce Momjian said: >[EMAIL PROTECTED] wrote: >> Further to my earlier e-mail, there would have to be two lines added to >> conversion_create.sql for each alternate function name >> >> Like: >> >> CREATE OR REPLACE FUNCTION ascii_to_whatever (INTEGER, INTEGER, CSTRING, >> CSTRING, INTEGER) RETURNS VOID AS '$libdir/ascmic', 'ascii_to_mic' >> LANGUAGE 'c' STRICT; >> >> CREATE CONVERSION pg_catalog.ascii_to_whatever FOR 'SQL_ASCII' TO >> 'MULE_INTERNAL' FROM ascii_to_whatever; >I would like to avoid bloating the system with aliases. I think it is OK >to have it happen with specific names but doing it for all the >combinations is too much, and these duplicates are in the system tables, >not in the C code. It just doesn't seem worth it to me. Good point, perhaps having a script generated that can be executed by the DBA to insert any deprecated conversion routine names would be the best route to take. That way they would only be there if needed by the particular installation. -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] [BUGS] BUG #1466: #maintenace_work_mem = 16384
Patch applied. Thanks. I assume this is not for 8.0.X. --- Magnus Hagander wrote: > >>> The proposed test on Redirect_stderr looks pretty fishy too; for one > >>> thing it will almost certainly not be the right thing > >inside the stderr > >>> logger subprocess itself. > > > >> Could you explain further what the issue is there? > > > >Inside the logger subprocess, Redirect_stderr is guaranteed true (since > >it'll be inherited from the postmaster) and therefore the proposed > >change ensures that anything the logger might want to complain about > >goes to the original stderr, ie, into the bit bucket rather than > >someplace useful. Perhaps something like > > > > if ((!Redirect_stderr || am_syslogger) && pgwin32_is_service()) > > > >would be reasonable. > > > > Here is an updated patch, that should take care of this. Tested that it > solves the problem reported. > > > >> There is special code in the send_message_to_server_log > >function to make > >> sure it's written directly to the file. > > > >If the logger is complaining, it's quite possibly because it's > >unable to > >write to its file. Now that you mention it, doesn't this code go into > >infinite recursion if write_syslogger_file_binary() tries to ereport? > > > > I haven't looked at this part, it appears a separate (but closely > related) issue. > > Perhaps Andreas can comment on this? > > //Magnus Content-Description: stderr.patch [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faq -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [HACKERS] UTF8 or Unicode
[EMAIL PROTECTED] wrote: > In <[EMAIL PROTECTED]>, on 02/26/05 >at 07:55 PM, Bruce Momjian said: > > >[EMAIL PROTECTED] wrote: > >> Further to my earlier e-mail, there would have to be two lines added to > >> conversion_create.sql for each alternate function name > >> > >> Like: > >> > >> CREATE OR REPLACE FUNCTION ascii_to_whatever (INTEGER, INTEGER, CSTRING, > >> CSTRING, INTEGER) RETURNS VOID AS '$libdir/ascmic', 'ascii_to_mic' > >> LANGUAGE 'c' STRICT; > >> > >> CREATE CONVERSION pg_catalog.ascii_to_whatever FOR 'SQL_ASCII' TO > >> 'MULE_INTERNAL' FROM ascii_to_whatever; > > >I would like to avoid bloating the system with aliases. I think it is OK > >to have it happen with specific names but doing it for all the > >combinations is too much, and these duplicates are in the system tables, > >not in the C code. It just doesn't seem worth it to me. > > Good point, perhaps having a script generated that can be executed by the > DBA to insert any deprecated conversion routine names would be the best > route to take. I am unsure why anyone would use the awkward names when you can more easily supply the actual encoding names, and all the aliases work there. Also, consider this is going to be a major release change so they are going to dump/reload anyway. I see I need to update conversion_create.sql too. I was previously only looking in C files. Let me do a bigger search. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
