An uncommitted select of the new pseudo table sec$users (CORE-2639) seems to
block new database connections
---
Key: CORE-4200
URL:
On 27-8-2013 20:12, Adriano dos Santos Fernandes wrote:
On 27/08/2013 15:06, Leyne, Sean wrote:
I think an USING clause would be a great addition:
GENERATED BY DEFAULT AS IDENTITY [USING SEQUENCE name]
What do you think?
What Sequence (name) would be used if the USING was omitted?
A
On 29-8-2013 17:41, Jim Starkey wrote:
Paradoxically, Japanese strings tend to be shorter in UTF-8 than 16 bit
Unicode. The reason is simple: There are enough single byte characters
-- punctuation, control characters, and digits -- stay as single bytes,
double byte characters are a wash, and
31.08.2013 10:55, Mark Rotteveel wrote:
I'd prefer to have an option to use UTF-16 (treated as a 2-byte
character set with surrogate pairs) as that will only halve the maximum
allowed number of characters.
Nope. If you take into account surrogates, UTF-16 will have the same maximum
of 4
31.08.2013 13:53, Mark Rotteveel wrote:
On 31-8-2013 13:38, Dimitry Sibiryakov wrote:
31.08.2013 13:29, Mark Rotteveel wrote:
As most languages don't need those surrogate pairs for their
codepoints/glyphs, it is easier to consider UTF-16 to be 2 byte. As far
as I know this is how most UTF-16
computed field has null value inside BI trigger
---
Key: CORE-4201
URL: http://tracker.firebirdsql.org/browse/CORE-4201
Project: Firebird Core
Issue Type: Bug
Components: Engine
On Aug 31, 2013, at 4:55 AM, Mark Rotteveel m...@lawinegevaar.nl wrote:
On 29-8-2013 17:41, Jim Starkey wrote:
Paradoxically, Japanese strings tend to be shorter in UTF-8 than 16 bit
Unicode. The reason is simple: There are enough single byte characters
-- punctuation, control characters,
I think this is correct - if unexplicable - behavior according to the Standard.
Something about the state of the coulmn prior to the operation.
On Aug 31, 2013, at 8:13 AM, Gorynich (JIRA) trac...@firebirdsql.org wrote:
computed field has null value inside BI trigger
01.09.2013 06:29, Ann Harrison wrote:
I think this is correct - if unexplicable - behavior according to the
Standard. Something about the state of the column prior to the operation.
I respectfully disagree. The NEW context is in the perfectly valid state
in the BEFORE INSERT triggers. If
