SQL injection vulnerabilities in PostgreSQL [LWN.net]

SQL injection vulnerabilities in PostgreSQL

Posted Jun 2, 2006 0:41 UTC (Fri) by dlang (subscriber, #313)
In reply to: SQL injection vulnerabilities in PostgreSQL by nim-nim
Parent article: SQL injection vulnerabilities in PostgreSQL

frankly I want software that doesn't require i18n to be turned on. processing multi-byte characters is slower then processing single byte characters (for a number of reasons). I don't want to pay that overhead for systems that don't need it (and face it, most systems really don't need it, that's why the world survived with ascii for so long)

as for the gui folks, it's not the pixles that are the issue, but the assumption that the gui software has the right to take the entire screen. if they didn't assume that they had the entire screen then the shape of that screen wouldn't matter

(Log in to post comments)

internationalisation

Posted Jun 2, 2006 2:33 UTC (Fri) by xoddam (subscriber, #2322) [Link]

> frankly I want software that doesn't require i18n to be turned on.

If the software supports internationalisation at all, then 'just ASCII
thanks' is one particular localisation, and there's nothing to switch
off. A little extra optimisation for this case wouldn't be a bad idea
though.

> processing multi-byte characters is slower then processing
> single byte characters (for a number of reasons).

UTF8 helps with this as long as the vast majority of your characters are
in the ASCII range. But UTF8 has its own minor performance headaches,
particularly in Eastern Asian locales where a 16-bit character is much
more convenient.

A significant annoyance and performance issue is when such things as
font-measuring have per-character primitive methods that take a UCS32
parameter, and the string must be expanded repeatedly to its individual
characters (or cached as an array of 32-bit values). Bringing the whole
UTF (8 or 16) string right down to the lowest level might eliminate some
of that overhead.

> that's why the world survived with ascii for so long

The world? For 'so long'? For how long exactly was the *American*
Standard the sole character set encoding in *any* non-English-language
environment? The earliest Japanese derivatives of ASCII began to be
*standardised* in 1969 (JIS C 6220), while the US computing community was
still worrying about converting between ASCII and ECBDIC.

SQL injection vulnerabilities in PostgreSQL

Posted Jun 2, 2006 7:45 UTC (Fri) by nim-nim (subscriber, #34454) [Link]

You would be right but for the internet.

When systems were not interconnected, or the interconnect was slow and limited, local encodings worked fine. Nowadays with dataflows all over the world local-encoding-only systems are the exception not the norm (show me an ascii-only system and I'm almost sure any serious investigation will find users frustrated by its encoding limitations)

And anyway optimising for the ascii case when you end up turning i18n anyway is wrong on so many levels (speed, security) I won't expand on it.