On 5-9-2013 16:45, Jim Starkey wrote:
> The keys to reducing round trips are to bundle metadata with data to
> eliminate the need for "info" trips and, most importantly, to batch
> record retrievals and batch inserts into single large packets. Sending a
> MB worth of records is obviously a great wi
On 09/05/13 18:45, Jim Starkey wrote:
> On 9/5/2013 4:28 AM, Alex Peshkoff wrote:
>> On 09/04/13 18:11, Jim Starkey wrote:
>>
>>> So here's another seriously heretical thought. If you're planning for
>>> Firebird to hang around another 27 years, it's time to define a modern
>>> OO API that is easy
On 05/09/13 15:45, Jim Starkey wrote:
> While I was pointing out that the worst part of
> starting a new software company was rewriting "stringToDate", a
> completely new, incredibly efficient, open ended algorithm for that
> class of conversions occurred to me. It's really cute, and if anyone is
On 9/5/2013 4:28 AM, Alex Peshkoff wrote:
> On 09/04/13 18:11, Jim Starkey wrote:
>
>> So here's another seriously heretical thought. If you're planning for
>> Firebird to hang around another 27 years, it's time to define a modern
>> OO API that is easy to use from modern languages, is flexible an
On 09/04/13 18:11, Jim Starkey wrote:
> So here's another seriously heretical thought. If you're planning for
> Firebird to hang around another 27 years, it's time to define a modern
> OO API that is easy to use from modern languages, is flexible and
> extensible, supports an efficient remote pro
A clob is nothing but a blob that is thought to be character.
On 9/4/2013 6:40 AM, Adriano dos Santos Fernandes wrote:
> On 04/09/2013 05:09, Alex Peshkoff wrote:
>> On 09/04/13 11:53, Dmitry Yemanov wrote:
>>> 04.09.2013 11:43, Alex Peshkoff wrote:
May be in that case next step? Keep declari
On 04/09/2013 11:00, Jim Starkey wrote:
> a blob that is thought to be character
And a string with unlimited length is nothing than "a blob that is
thought to be character".
If you implement it efficiently or not, is another matter.
Adriano
-
Unbounded types work very badly with the SQLDA. The original SQLDA was
lifted verbatim from the DB2 spec, circa 1985, because I wanted
something more or less standard. It was pretty much awful then and it
hasn't gotten much prettier since. On the other hand, it's what
everything uses for Fir
04.09.2013 13:08, Alex Peshkoff wrote:
> You
> will anyway not be able to fit long sql names, schemas and a lot of
> other things into SQLDA.
May be. But otherwise I'll have problem to keep compatibility with all
existing versions.
--
WBR, SD.
On 09/04/13 14:59, Dimitry Sibiryakov wrote:
> 04.09.2013 12:56, Alex Peshkoff wrote:
>> Not sure it will be supported in SQLDA API...
> Why not?
That all is about the future version of firebird, let's call it FB4.
Certainly (hmm, at least on my mind) we will continue supporting
backward cpm
04.09.2013 12:56, Alex Peshkoff wrote:
> Not sure it will be supported in SQLDA API...
Why not? There are at least two ways: "client-side" blob id and
clent-assigned sqldata.
--
WBR, SD.
--
Learn the latest--Visu
On 09/04/13 14:46, Dimitry Sibiryakov wrote:
> 04.09.2013 12:40, Adriano dos Santos Fernandes wrote:
>> The name of this type, a long and unlimited string, is CLOB.
> But what value will be in XSQLVAR.sqltype?
>
Not sure it will be supported in SQLDA API...
--
04.09.2013 12:40, Adriano dos Santos Fernandes wrote:
> The name of this type, a long and unlimited string, is CLOB.
But what value will be in XSQLVAR.sqltype?
--
WBR, SD.
--
Learn the latest--Visual Studio 2012,
On 04/09/2013 05:09, Alex Peshkoff wrote:
> On 09/04/13 11:53, Dmitry Yemanov wrote:
>> 04.09.2013 11:43, Alex Peshkoff wrote:
>>> May be in that case next step? Keep declaring strings as char(N), but
>>> treat N not as maximum size of string
>> Please don't play against the SQL standard. The decla
> On 09/04/13 11:53, Dmitry Yemanov wrote:
>> 04.09.2013 11:43, Alex Peshkoff wrote:
>>> May be in that case next step? Keep declaring strings as char(N), but
>>> treat N not as maximum size of string
>> Please don't play against the SQL standard. The declared string length
>> is a constraint which
On 09/04/13 11:53, Dmitry Yemanov wrote:
> 04.09.2013 11:43, Alex Peshkoff wrote:
>> May be in that case next step? Keep declaring strings as char(N), but
>> treat N not as maximum size of string
> Please don't play against the SQL standard. The declared string length
> is a constraint which must b
04.09.2013 11:43, Alex Peshkoff wrote:
>
> May be in that case next step? Keep declaring strings as char(N), but
> treat N not as maximum size of string
Please don't play against the SQL standard. The declared string length
is a constraint which must be enforced.
Dmitry
-
On 09/03/13 19:32, Jim Starkey wrote:
> 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 b
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
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
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
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
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
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
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:
28 matches
Mail list logo
