On 4-1-2017 11:30, Dmitry Yemanov wrote:
> 04.01.2017 13:13, Dimitry Sibiryakov wrote:
>>
>> "This has the added benefit that tools can use this information to determine
>> the data
>> type consistently based on type and subtype".
>
> AFAIU, ticket suggests to match API's subtype also to field's
On 01/04/17 13:51, Dimitry Sibiryakov wrote:
> 04.01.2017 11:44, Alex Peshkoff wrote:
>> - why charset OCTETS should be represented as sybtype, not charset?
> Not charset, but type "BINARY". Even if it is just an alias, it deserves
> to be
> distinguishable from parent type the same way as
04.01.2017 11:44, Alex Peshkoff wrote:
> - why charset OCTETS should be represented as sybtype, not charset?
Not charset, but type "BINARY". Even if it is just an alias, it deserves to
be
distinguishable from parent type the same way as are INTEGER/DECIMAL/NUMERIC.
> - what else subtypes
On 01/04/17 13:30, Dmitry Yemanov wrote:
> 04.01.2017 13:13, Dimitry Sibiryakov wrote:
>> "This has the added benefit that tools can use this information to determine
>> the data
>> type consistently based on type and subtype".
> AFAIU, ticket suggests to match API's subtype also to field's
04.01.2017 11:30, Dmitry Yemanov wrote:
> AFAIU, ticket suggests to match API's subtype also to field's subtype,
> in addition to matching it to the field's charset/collation.
AFAIU, it was suggested only for compatibility with ISC API which is
deprecated anyway.
> But IMO it
> means that we
04.01.2017 13:13, Dimitry Sibiryakov wrote:
>
> "This has the added benefit that tools can use this information to determine
> the data
> type consistently based on type and subtype".
AFAIU, ticket suggests to match API's subtype also to field's subtype,
in addition to matching it to the
04.01.2017 11:06, Alex Peshkoff wrote:
> Sooner of all I'm missing something but please explain - what is the
> difference between them?
"RDB$FIELD_SUB_TYPE (in RDB$FIELDS and RDB$FUNCTION_ARGUMENTS)".
> I'm not sure what do we win with suggested change.
"This has the added benefit that
On 01/03/17 18:33, Dimitry Sibiryakov wrote:
> 30.12.2016 17:06, Dmitry Yemanov wrote:
>>> Do anybody object if I try to dig a little into CORE-5064?
>> No, feel free.
> I've managed to make binary strings accessible at sql level, but found
> that whole
> engine, starting from dsc is not
30.12.2016 17:06, Dmitry Yemanov wrote:
>> Do anybody object if I try to dig a little into CORE-5064?
> No, feel free.
I've managed to make binary strings accessible at sql level, but found that
whole
engine, starting from dsc is not prepared to handle sql_sub_type and character
set
30.12.2016 18:05, Dimitry Sibiryakov wrote:
> Do anybody object if I try to dig a little into CORE-5064?
No, feel free.
Dmitry
--
Check out the vibrant tech community on one of the world's most
engaging tech sites,
30.12.2016 15:59, Alex Peshkoff wrote:
> Definitely not limited. But it's good idea to discuss new feature before
> implementing it (specially if it's not already in the tracker).
Ok. Do anybody object if I try to dig a little into CORE-5064?
--
WBR, SD.
On 12/30/16 17:54, Dimitry Sibiryakov wrote:
> Hello, All.
>
> Is list of features for version 4 limited to listed in roadmap?
> I.e. if I pull request for something else will it be rejected for sure?
Definitely not limited. But it's good idea to discuss new feature before
12 matches
Mail list logo
