Badly selective index could be used for extra filtering even if selective index
is used for sorting
---
Key: CORE-5435
URL:
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
