Re: [Firebird-devel] Firebird 4 features
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 subtype, > in addition to matching it to the field's charset/collation. But IMO it > means that we cannot have other subtypes for strings in the future. I.e. > subtype 4 cannot be anything else than UTF8 and so on. This looks too > much limiting. My suggestion actually doesn't do that, I just suggested using 1 because it would be the first subtype. Maybe I should not have mentioned CS_BINARY there at all. Mark -- Mark Rotteveel -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 4 features
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 are INTEGER/DECIMAL/NUMERIC. > >> - what else subtypes make sense for character fields (I understand that >> we may place BLR or even small JPEG data into VARCHAR, but does it >> really make sense to do such things) ? > I would suggest to separate GUID. > > OK, that makes sense. Returning to your initial question - I think we should start with having just an alias (not subtype) and next think about adding character string subtypes to engine - but please wait what can other people say. BTW, what does standard say about string subtype? -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 4 features
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 make sense for character fields (I understand that > we may place BLR or even small JPEG data into VARCHAR, but does it > really make sense to do such things) ? I would suggest to separate GUID. -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 4 features
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 subtype, > in addition to matching it to the field's charset/collation. But IMO it > means that we cannot have other subtypes for strings in the future. I.e. > subtype 4 cannot be anything else than UTF8 and so on. This looks too > much limiting. > But what is a reason for mixing subtype and character set at all? That is very bad idea in general. One case is when we talk about subtypes in blobs - that could be thing like BLR, ACL, SDL, JPEG and other graphical formats, etc. Yes, certainly charset is also a kind of format (i.e. a rule how to interpret correctly) for a data, contained in a character field. But we already have a working charsets feature for it! May be first 2 questions should be: - why charset OCTETS should be represented as sybtype, not charset? (reasons provided in the tracker do not look serious) - what else subtypes make sense for character fields (I understand that we may place BLR or even small JPEG data into VARCHAR, but does it really make sense to do such things) ? -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 4 features
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 cannot have other subtypes for strings in the future. I.e. > subtype 4 cannot be anything else than UTF8 and so on. This looks too > much limiting. Not quite so. In new API subtype and charset are independent things. -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 4 features
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 field's charset/collation. But IMO it means that we cannot have other subtypes for strings in the future. I.e. subtype 4 cannot be anything else than UTF8 and so on. This looks too much limiting. Dmitry -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 4 features
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 tools can use this information to determine the data type consistently based on type and subtype". -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 4 features
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 prepared to handle sql_sub_type and > character set > separately. Thus isql and API has no way to distinguish between "varchar(10) > character set > octets" and "varbinary(10)". Sooner of all I'm missing something but please explain - what is the difference between them? From http://tracker.firebirdsql.org/browse/CORE-5064 I see that varbinary is just an alias for old syntax. What about the phraze: "Using either the alias or the 'old' full definition should become an explicit subtype of CHAR and VARCHAR, instead of implicit based on the character set id as it is now" I'm not sure what do we win with suggested change. > Should I dig deeper and separate them everywhere through engine or to > offer patch as is? > > -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 4 features
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 separately. Thus isql and API has no way to distinguish between "varchar(10) character set octets" and "varbinary(10)". Should I dig deeper and separate them everywhere through engine or to offer patch as is? -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 4 features
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, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 4 features
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. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 4 features
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 implementing it (specially if it's not already in the tracker). -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
