Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

main.c

Blame
    • Noah Misch's avatar
      5f538ad0
      Renovate display of non-ASCII messages on Windows. · 5f538ad0
      Noah Misch authored
      GNU gettext selects a default encoding for the messages it emits in a
      platform-specific manner; it uses the Windows ANSI code page on Windows
      and follows LC_CTYPE on other platforms.  This is inconvenient for
      PostgreSQL server processes, so realize consistent cross-platform
      behavior by calling bind_textdomain_codeset() on Windows each time we
      permanently change LC_CTYPE.  This primarily affects SQL_ASCII databases
      and processes like the postmaster that do not attach to a database,
      making their behavior consistent with PostgreSQL on non-Windows
      platforms.  Messages from SQL_ASCII databases use the encoding implied
      by the database LC_CTYPE, and messages from non-database processes use
      LC_CTYPE from the postmaster system environment.  PlatformEncoding
      becomes unused, so remove it.
      
      Make write_console() prefer WriteConsoleW() to write() regardless of the
      encodings in use.  In this situation, write() will invariably mishandle
      non-ASCII characters.
      
      elog.c has assumed that messages conform to the database encoding.
      While usually true, this does not hold for SQL_ASCII and MULE_INTERNAL.
      Introduce MessageEncoding to track the actual encoding of message text.
      The present consumers are Windows-specific code for converting messages
      to UTF16 for use in system interfaces.  This fixes the appearance in
      Windows event logs and consoles of translated messages from SQL_ASCII
      processes like the postmaster.  Note that SQL_ASCII inherently disclaims
      a strong notion of encoding, so non-ASCII byte sequences interpolated
      into messages by %s may yet yield a nonsensical message.  MULE_INTERNAL
      has similar problems at present, albeit for a different reason: its lack
      of libiconv support or a conversion to UTF8.
      
      Consequently, one need no longer restart Windows with a different
      Windows ANSI code page to broadly test backend logging under a given
      language.  Changing the user's locale ("Format") is enough.  Several
      accounts can simultaneously run postmasters under different locales, all
      correctly logging localized messages to Windows event logs and consoles.
      
      Alexander Law and Noah Misch
      5f538ad0
      History
      Renovate display of non-ASCII messages on Windows.
      Noah Misch authored
      GNU gettext selects a default encoding for the messages it emits in a
      platform-specific manner; it uses the Windows ANSI code page on Windows
      and follows LC_CTYPE on other platforms.  This is inconvenient for
      PostgreSQL server processes, so realize consistent cross-platform
      behavior by calling bind_textdomain_codeset() on Windows each time we
      permanently change LC_CTYPE.  This primarily affects SQL_ASCII databases
      and processes like the postmaster that do not attach to a database,
      making their behavior consistent with PostgreSQL on non-Windows
      platforms.  Messages from SQL_ASCII databases use the encoding implied
      by the database LC_CTYPE, and messages from non-database processes use
      LC_CTYPE from the postmaster system environment.  PlatformEncoding
      becomes unused, so remove it.
      
      Make write_console() prefer WriteConsoleW() to write() regardless of the
      encodings in use.  In this situation, write() will invariably mishandle
      non-ASCII characters.
      
      elog.c has assumed that messages conform to the database encoding.
      While usually true, this does not hold for SQL_ASCII and MULE_INTERNAL.
      Introduce MessageEncoding to track the actual encoding of message text.
      The present consumers are Windows-specific code for converting messages
      to UTF16 for use in system interfaces.  This fixes the appearance in
      Windows event logs and consoles of translated messages from SQL_ASCII
      processes like the postmaster.  Note that SQL_ASCII inherently disclaims
      a strong notion of encoding, so non-ASCII byte sequences interpolated
      into messages by %s may yet yield a nonsensical message.  MULE_INTERNAL
      has similar problems at present, albeit for a different reason: its lack
      of libiconv support or a conversion to UTF8.
      
      Consequently, one need no longer restart Windows with a different
      Windows ANSI code page to broadly test backend logging under a given
      language.  Changing the user's locale ("Format") is enough.  Several
      accounts can simultaneously run postmasters under different locales, all
      correctly logging localized messages to Windows event logs and consoles.
      
      Alexander Law and Noah Misch