> -Original Message-
> From: Alex Peshkoff [mailto:peshk...@mail.ru]
> Sent: Viernes, 23 de Mayo de 2014 6:05
>
> On 05/23/14 13:59, Dimitry Sibiryakov wrote:
> > 23.05.2014 11:54, Alex Peshkoff wrote:
> >> Did you read that this is mask, not code? It's anyway
> impossible to join
> >> d
On Fri, May 23, 2014 at 3:03 AM, Paul Beach wrote:
>
> >>> - Any other suggestion?
> >>
> >> Drop dialect 1 support.
> >
> > Allow dialect 1 to have access to BIGINT fields.
>
>
For what little it's worth,
a) Dialect 1 did include 64bit integers at one time. VAX's had a native
64 bit integer
On Fri, 23 May 2014 13:02:32 +0200, "Paul Beach"
wrote:
> < support was already done with Interbase 6.0. The Interbase 6.0 Getting
> Started Guide explicitly states that moving from Interbase 5 to
Interbase 6
> you need to migrate databases and clients from dialect 1 to 3. It also
says
> (page 27)
23.05.2014 13:04, Martijn Tonies (Upscene Productions) wrote:
> Also, I'm not quite getting how a bit mask can be a list of normal numbers,
> but this may be just me being confused.
No, I also have no idea how to corellate data in RDB$TYPES with all the rest.
--
WBR, SD.
-
23.05.2014 13:55, Dimitry Sibiryakov wrote:
> 23.05.2014 12:48, Vlad Khorsun wrote:
>> This "useless garbage" is required for self-documenting
>
> Self-documenting of what?
Self-documenting of constants used to encode some values in system
tables in database.
> Isn't list in header e
What Thomas said. ;)
Also, I'm not quite getting how a bit mask can be a list of normal numbers,
but
this may be just me being confused.
With regards,
Martijn Tonies
Upscene Productions
http://www.upscene.com
Download Database Workbench for Oracle, MS SQL Server, Sybase SQL
Anywhere, MySQL, In
On Fri, 23 May 2014 09:03:35 +0200, "Paul Beach"
wrote:
- Any other suggestion?
>>>
>>> Drop dialect 1 support.
>>
>> Allow dialect 1 to have access to BIGINT fields.
>
> <
> but the question that arises is "why?"
>
> What are the reasons to continue to use dialect 1?>>
>
> Because ther
On 05/23/14 14:55, Dimitry Sibiryakov wrote:
> 23.05.2014 12:48, Vlad Khorsun wrote:
>> This "useless garbage" is required for self-documenting
> Self-documenting of what? Isn't list in header enough for this purpose?..
>
Currently it's placed in a header, not distributed with binary packages.
On Fri, 23 May 2014 12:55:26 +0200, Dimitry Sibiryakov
wrote:
> 23.05.2014 12:48, Vlad Khorsun wrote:
>> This "useless garbage" is required for self-documenting
>
>Self-documenting of what? Isn't list in header enough for this
>purpose?..
No, because looking in the source of Firebird for
>> This "useless garbage" is required for self-documenting
>
>Self-documenting of what? Isn't list in header enough for this purpose?..
No: Not everybody using firebird reads C-code.
Thomas
--
Diplom-Informatiker
Wielandstraße 14c • 23558 Lübeck
Tel +49 (22 25) 91 34 - 545 • Fax +49 (22 2
23.05.2014 12:48, Vlad Khorsun wrote:
> This "useless garbage" is required for self-documenting
Self-documenting of what? Isn't list in header enough for this purpose?..
--
WBR, SD.
--
"Accelerate Dev Cycles with
23.05.2014 12:43, Dimitry Sibiryakov wrote:
> 23.05.2014 11:29, Alex Peshkoff wrote:
>> It's not absolutely required to have bigint column - it's enough to
>> store bit number, which is less than 64.
>
> It makes impossible to use JOIN to retrieve trigger's type via SQL query.
> In this case
>
On Fri, 23 May 2014 11:43:56 +0200, Dimitry Sibiryakov
wrote:
> 23.05.2014 11:29, Alex Peshkoff wrote:
>> It's not absolutely required to have bigint column - it's enough to
>> store bit number, which is less than 64.
>
>It makes impossible to use JOIN to retrieve trigger's type via SQL
>
On Fri, 23 May 2014 09:03:35 +0200, "Paul Beach"
wrote:
- Any other suggestion?
>>>
>>> Drop dialect 1 support.
>>
>> Allow dialect 1 to have access to BIGINT fields.
>
> <
> but the question that arises is "why?"
>
> What are the reasons to continue to use dialect 1?>>
>
> Because ther
On 05/23/14 13:59, Dimitry Sibiryakov wrote:
> 23.05.2014 11:54, Alex Peshkoff wrote:
>> Did you read that this is mask, not code? It's anyway impossible to join
>> directly, but with some functions - why not.
> With mask it is possible to use LIST() and BIT_AND() to get list of
> triggers wit
23.05.2014 11:54, Alex Peshkoff wrote:
> Did you read that this is mask, not code? It's anyway impossible to join
> directly, but with some functions - why not.
With mask it is possible to use LIST() and BIT_AND() to get list of triggers
with
actions. With bit number it won't work because of
On 05/23/14 13:43, Dimitry Sibiryakov wrote:
> 23.05.2014 11:29, Alex Peshkoff wrote:
>> It's not absolutely required to have bigint column - it's enough to
>> store bit number, which is less than 64.
> It makes impossible to use JOIN to retrieve trigger's type via SQL query.
> In this case
>
23.05.2014 11:29, Alex Peshkoff wrote:
> It's not absolutely required to have bigint column - it's enough to
> store bit number, which is less than 64.
It makes impossible to use JOIN to retrieve trigger's type via SQL query. In
this case
there is no point to pollute RDB$TYPES with useless ga
On 05/23/14 10:14, Martijn Tonies (Upscene Productions) wrote:
Yes, it's a bit mask. See the constants:
>>> Shouldn't it be present in RDB$TYPES, as all other
>>> "special" numbers ?
Definitely yes.
>> I have them commented in my private sources for types.h, but the problem
>> is:
>> ho
23.05.2014 8:41, Martijn Tonies (Upscene Productions) wrote:
> but the question that arises is "why?"
>
> What are the reasons to continue to use dialect 1?
Mathematic, for example. Standard behavior of division which dialect 3
supports is not
the best idea.
--
WBR, SD.
- Any other suggestion?
>>>
>>> Drop dialect 1 support.
>>
>> Allow dialect 1 to have access to BIGINT fields.
>
><
>but the question that arises is "why?"
>
>What are the reasons to continue to use dialect 1?>>
>
>Because there are large numbers of databases out there still using it...
Col
>>> - Any other suggestion?
>>
>> Drop dialect 1 support.
>
> Allow dialect 1 to have access to BIGINT fields.
<>
Because there are large numbers of databases out there still using it...
and if we are going to drop support for dialect 1, we should announce it
well in advance, not at alpha sta
On 05/23/14 10:47, Dmitry Yemanov wrote:
> 23.05.2014 10:24, Dimitry Sibiryakov wrote:
>
>> Allow dialect 1 to have access to BIGINT fields.
> I have a feeling that Adriano already did that for v3.
Yes, a few months ago.
W/o that change database triggers did not work correctly in dialect1
databas
23 matches
Mail list logo
