libedit will be updated and patched for 2.5.x branch also ?
I ask this because in debian libedit2 i s already updated and it would
be nice if also in the 2.5.x branch would be done so
http://packages.debian.org/sid/libedit2
[
http://tracker.firebirdsql.org/browse/CORE-4185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Peshkov reopened CORE-4185:
-
Fix is incomplete and wrong
> FB craches with "invalid lock id (N), errno: 0" when all co
>>> 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.
The maximum allowed number of characters in Unicode is about 1
Million. Which can be perfectly represented by either UTF
On Mon, Sep 02, 2013 at 03:30:26PM +0200, Stefan Heymann 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.
>
> The maximum allowed number of characters in Un
On 09/02/13 16:06, marius adrian popa wrote:
> libedit will be updated and patched for 2.5.x branch also ?
>
> I ask this because in debian libedit2 i s already updated and it would
> be nice if also in the 2.5.x branch would be done so
>
I think that all distros, not debian only, support fresh ed
OK, here's another "humble" suggestion that folks might want to consider
for a future version: Support an "upgrade " syntactically
parallel to "create ". The "upgrade" version, however, takes
the existing object, compares it to the described object, and makes any
changes necessary. If they a
Let me offer another humble suggestion, though one that should not be a
candidate for FB3: Ditch the concept of fixed length records,
completely and forever.
Let me sketch the scheme I used in Netfrastructure / Falcon, which
originated from a suggestion on this list. The key elements are:
> Unfortunately the implementation of UTF-8 in Firebird is annoying
> because it reduces that maximum allowed number of characters to a 1/4 of
> that for single byte character sets making it necessary to switch to
> blobs sooner.
IIRC, old Interbase versions defined maximum Varchar length in *byte
On 02.09.2013 17:04, Alex Peshkoff wrote:
> On 09/02/13 16:06, marius adrian popa wrote:
>> libedit will be updated and patched for 2.5.x branch also ?
>>
>> I ask this because in debian libedit2 i s already updated and it would
>> be nice if also in the 2.5.x branch would be done so
>>
>
> I think
