Error when compiling the procedure containing the statement if (x = (select
...))
-
Key: CORE-4204
URL: http://tracker.firebirdsql.org/browse/CORE-4204
Project: Firebird
On 9/3/2013 8:02 AM, Alex Peshkoff wrote:
> On 09/03/13 13:21, Dmitry Yemanov wrote:
>> 03.09.2013 11:13, Alex Peshkoff wrote:
>>
>>> That's definitely a candidate for next ODS. But I see one problem -
>>> currently all (or at least most of all) record buffers are allocated at
>>> prepare time. Wit
Cannot create packaged routines with [VAR]CHAR parameters
-
Key: CORE-4203
URL: http://tracker.firebirdsql.org/browse/CORE-4203
Project: Firebird Core
Issue Type: Bug
Affects Versio
On Tue, Sep 3, 2013 at 5:04 AM, Dimitry Sibiryakov wrote:
>
>What problem do you foresee?
>AFAIK, ccess to single field values is already incapsulated in record
> class, so string
> buffer in DSC can be replaced with pointer without hacking whole engine.
> So, only SQZ
> module should be
Backup/Restore
--
Key: CORE-4202
URL: http://tracker.firebirdsql.org/browse/CORE-4202
Project: Firebird Core
Issue Type: Bug
Affects Versions: 3.0 Alpha 1
Environment: Software platform
Reporter: Renan Ro
Seems the right way , so less privileges = is better
On Fri, Aug 30, 2013 at 2:46 PM, Alex Peshkoff wrote:
> Hello all!
>
> In posix builds since FB2.0 we use 'firebird' runuser as default, but
> support (at least on linux) scripts to switch between 'firebird' and
> 'root' runusers. It's clear th
On 09/03/13 13:21, Dmitry Yemanov wrote:
> 03.09.2013 11:13, Alex Peshkoff wrote:
>
>> That's definitely a candidate for next ODS. But I see one problem -
>> currently all (or at least most of all) record buffers are allocated at
>> prepare time. With variable record length this strategy requires c
On Tue, Sep 03, 2013 at 12:02:51PM +0400, Alex Peshkoff wrote:
> No matter of this licensing issue almost all (correct be if
> I'm wrong) distros use --with-system-editline switch and distribute
> firebird packages violating GPL.
It would be GPL violation if a distribution package comp
03.09.2013 11:22, Alex Peshkoff wrote:
> Add dynamic allocation to SQZ?
No.
SQZ pack RecordBuffer into fixed-size pages, there is no need for dynamic
allocation there.
Dynamic allocation is needed in RecordBuffer only and only for strings.
--
WBR, SD.
--
On 09/03/13 13:04, Dimitry Sibiryakov wrote:
> 03.09.2013 9:13, Alex Peshkoff wrote:
>> But I see one problem -
>> currently all (or at least most of all) record buffers are allocated at
>> prepare time. With variable record length this strategy requires change,
>> and that change does not look tri
03.09.2013 11:13, Alex Peshkoff wrote:
> That's definitely a candidate for next ODS. But I see one problem -
> currently all (or at least most of all) record buffers are allocated at
> prepare time. With variable record length this strategy requires change,
> and that change does not look trivial
03.09.2013 9:13, Alex Peshkoff wrote:
> But I see one problem -
> currently all (or at least most of all) record buffers are allocated at
> prepare time. With variable record length this strategy requires change,
> and that change does not look trivial at the first glance.
What problem do you f
Am 03.09.2013 10:47, schrieb Alex Peshkoff:
> On 09/03/13 11:43, Frank Schlottmann-Gödde wrote:
>
> To be precise I'm not sure why did that guy need automake at all :-)
> It's required only if one touch Makefile.am. For regular builds existing
> in the tree configure is OK.
> May be it's really
Am 03.09.2013 10:02, schrieb Alex Peshkoff:
> The main reason why do we include libedit at all is licensing
Yes we had a discussion on this topic with a debian maintainer back in
2002 when we had to replace calls to readline with editline.
> - built
> into all known to me distros libreadline (it
On 09/03/13 11:43, Frank Schlottmann-Gödde wrote:
> Hm, I had to run autoreconf etc. on it to build it on Ubuntu 8.04
>
Did you try with initial package or with one we have in the tree?
Must say I've generated configure myself (on fresh gentoo) cause
Makefile.am was slightly modified - I've remo
Morning all,
be gentle with me, I'm not all that good a developer! ;-)
Given the problem with varchars being defined in bytes but needing to
store chars, how feasible would it be to allow the definition of a
column (or variable) in a manner similar to how Oracle does it?
create table ...(
a_c
On 09/03/13 11:34, Frank Schlottmann-Gödde wrote:
> Am 03.09.2013 09:13, schrieb Michal Kubecek:
>> On Tue, Sep 03, 2013 at 07:14:45AM +0200, Frank Schlottmann-Gödde wrote:
>>> On 02.09.2013 17:04, Alex Peshkoff wrote:
I think that all distros, not debian only, support fresh editline
libr
Am 03.09.2013 09:08, schrieb Alex Peshkoff:
> On 09/03/13 09:14, Frank Schlottmann-Gödde wrote:
>> 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 libed
Am 03.09.2013 09:13, schrieb Michal Kubecek:
> On Tue, Sep 03, 2013 at 07:14:45AM +0200, Frank Schlottmann-Gödde wrote:
>> On 02.09.2013 17:04, Alex Peshkoff wrote:
>>>
>>> I think that all distros, not debian only, support fresh editline
>>> library. And (provided they build --with-sustem-editline
On 09/03/13 11:02, Kjell Rilbe wrote:
> Den 2013-09-02 16:53 skrev Jim Starkey såhär:
>> 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.
> I really really really like this!
>
That's
On Tue, Sep 03, 2013 at 07:14:45AM +0200, Frank Schlottmann-Gödde wrote:
> On 02.09.2013 17:04, Alex Peshkoff wrote:
> >
> > I think that all distros, not debian only, support fresh editline
> > library. And (provided they build --with-sustem-editline, in which I'm
> > quite sure) they use it in fi
On 09/03/13 09:14, Frank Schlottmann-Gödde wrote:
> 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
Den 2013-09-02 16:53 skrev Jim Starkey såhär:
> 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.
I really really really like this!
Kjell
--
--
Kj
23 matches
Mail list logo