Loading ...
Sorry, an error occurred while loading the content.

Re: Ingperl patches, new version of DBD::Ingres

Expand Messages
  • Oyvind Gjerstad
    ... As a DBD-Informix _user_ I just wanted to say that the current behaviour of DBD::Informix has worked fine for me. I think the current behavoiur is both
    Message 1 of 15 , Oct 4, 2002
    View Source
    • 0 Attachment
      *** From dbi-users -- To unsubscribe, see the end of this message. ***

      >> I agree that an attribute could (and should) be added to control the
      > >> trimming or otherwise of the blanks. I'm not sure which is the better
      > >> default (to trim or not to trim; that is the question:-).

      As a DBD-Informix _user_ I just wanted to say that the current behaviour
      of DBD::Informix has worked fine for me. I think the current behavoiur
      is both sensible and logical. I have not (yet) come across problems caused
      by the trimmed char fields.
      --
      Øyvind Gjerstad Systems dept Tollpost-Globe AS N-6301 Åndalsnes/Norway
      E-mail: ogj@... Phone: +47 7122 6663 Fax: +47 7122 6694


      ------------------------------------------------------------------------------
      To unsubscribe from this list, please visit http://www.fugue.com/dbi.
      If you are without web access, or if you are having trouble with the web page,
      please send mail to dbi-request@.... Please try to use the web
      page first - it will take a long time for your request to be processed by hand.
      ------------------------------------------------------------------------------
    • Henrik Tougaard
      *** From dbi-users -- To unsubscribe, see the end of this message. *** ... They are my assumptions too. I still haven t found a place where trailing blanks are
      Message 2 of 15 , May 1, 1997
      View Source
      • 0 Attachment
        *** From dbi-users -- To unsubscribe, see the end of this message. ***

        On Wed, 30 Apr 1997, Tim Bunce wrote:

        > *** From dbi-users -- To unsubscribe, see the end of this message. ***
        >
        > > From: johnl@... (Jonathan Leffler)
        > >
        > > Regarding your discussion of trailing blanks on CHAR fields...
        > >
        > > DBD::Informix takes the view that since the trailing blanks on a CHAR
        > > field (as opposed to a VARCHAR field) are added automatically by the
        > > database system, they can be removed when they are fetched because (a)
        > > that's normally what people want, and (b) they do not convey significant
        > > information.
        >
        > I think those are dangerous assumptions.
        >
        They are my assumptions too. I still haven't found a place where trailing
        blanks are significant (and couldn't be added without problems) On the
        other hand I have often been burned by forgetting to trim the trailing
        blanks.

        > > I agree that an attribute could (and should) be added to control the
        > > trimming or otherwise of the blanks. I'm not sure which is the better
        > > default (to trim or not to trim; that is the question:-).
        >
        > It believe it should default to off but I am (just) open to arguments.
        >
        I would suggest that it should be controlled by ->{CompatMode}, ie.
        we leave everything as it is for the existing oraperl/ingperl scripts) and
        have the ned behaviour for the new DBD::Oracle, DBD::Ingres,
        DBD::Informix, ... scripts. (hey what about the existing DBD::Oracle
        scripts that rely on the trailing blanks? I just don't know. :-)

        > It blank trimming in DBD::Ingres and DBD::Informix applied only to
        > known CHAR type fields?
        >
        It should only be applied to CHAR fields - but I'll delay the whole thing
        waiting for this discussion to end with an agreement (and hopefully a new
        version of the DBI ;-)

        > > I believe that the trimming should be controllable at both the connection
        > > ($dbh) and statement ($sth) levels, and it should be possible to enquire
        > > for the trimming status on both $dbh and $sth.
        >
        > Sure.
        >
        Hear hear!

        > I'll name the DBI attribute TrimBlanks unless anyone has a better idea.
        I quite agree. Ingres has a function trim(text) that does this for 4gl
        programmers. Please don't lengthen it by add rigth_trim og such.

        --
        Henrik Tougaard ht@...
        Software Consultants, Copenhagen, Denmark
        #include <std.disclaim>



        ------------------------------------------------------------------------------
        To unsubscribe from this list, please visit http://www.fugue.com/dbi.
        If you are without web access, or if you are having trouble with the web page,
        please send mail to dbi-request@.... Please try to use the web
        page first - it will take a long time for your request to be processed by hand.
        ------------------------------------------------------------------------------
      • Tim Bunce
        ... Thanks but I m leaning your way now. See other message. ... I d still like to know that, if anyone knows. ... The attribute is (present tense - I ve just
        Message 3 of 15 , May 1, 1997
        View Source
        • 0 Attachment
          *** From dbi-users -- To unsubscribe, see the end of this message. ***

          > From: johnl@... (Jonathan Leffler)
          >
          > However, if the majority of DBD implementors (and users) think that the
          > correct default is not to trim the blanks, then DBD::Informix will follow
          > that standard.

          Thanks but I'm leaning your way now. See other message.

          > >Out of interest does anyone know what ODBC and JDBC do on this issue?

          I'd still like to know that, if anyone knows.

          > For example, what happens with the following sequence?
          >
          > Etc. And what happens if the sense of TrimBlanks is inverted at each
          > stage? I need to know what the expected behaviour is to be able to
          > implement it accurately for DBD::Informix. And users need to know what the
          > expected behaviour is to write their scripts so that the behaviour is as
          > they expect.

          The attribute is (present tense - I've just implemented it) held as a bit
          in the flags field of the handle. I have include the bit in the bit-mask
          which defines which bits are inherited by child handles. Thus the state
          of the bit at the time the child is created (prepare) is the initial
          state of the child. Clear?

          > Ultimately, we'll need similarly pedantic descriptions of
          > every part of the DBI interface.

          True. Volunteers welcome :-)

          Tim.


          ------------------------------------------------------------------------------
          To unsubscribe from this list, please visit http://www.fugue.com/dbi.
          If you are without web access, or if you are having trouble with the web page,
          please send mail to dbi-request@.... Please try to use the web
          page first - it will take a long time for your request to be processed by hand.
          ------------------------------------------------------------------------------
        • Tim Bunce
          ... Wasn t me. ... Nope. It doesn t. Do you remember all the people reporting problem with Oraperl when using CHAR fields? Basically DBD::Oracle uses VARCHARs
          Message 4 of 15 , May 1, 1997
          View Source
          • 0 Attachment
            *** From dbi-users -- To unsubscribe, see the end of this message. ***

            > From: descarte@...
            >
            > > Maybe, but I've not had anyone complain yet about that behaviour. I'm not
            > > even sure whether I put that in place or whether Alligator's code did it
            > > too.
            >
            > I think it might have been you....I don't recall putting something like that
            > in myself. Although, it may have been in DBD::Oracle, so we can both blame
            > Tim. 8-)

            Wasn't me.

            > > I absolutely agree about VARCHAR; if there are trailing blanks in VARCHAR
            > > data, then they are preserved. DBD::Informix only trims explicit CHAR data.
            > > It also doesn't touch BYTE and TEXT data (old-style blobs).
            >
            > Well, from Oracle's standpoint, CHARs are fixed length data, which, if
            > you specify a string shorter than the length of the field, it'll automatically
            > pad it. If you specify a longer string blank-padded, it'll trim it. If you
            > specify something too long, it chops it. So, I'm for trimming, I think.
            > Trailing-blanks aren't significant in CHARs, and VARCHAR will preserve them.
            > That's what Oracle will do anyway. If you SELECT a CHAR, Oracle should
            > automatically trim the value?

            Nope. It doesn't.

            Do you remember all the people reporting problem with Oraperl when using
            CHAR fields? Basically DBD::Oracle uses VARCHARs for bind parameters and so

            select * from table where char_field = ?

            didn't work unless the bind parameter had the right amount of space in it.
            The reason is that Oracle only performs space padded comparisons if _both_
            strings are fixed length (string literals are regarded as fixed length
            which is why "where char_field = 'foo'" works).

            I believe that's SQL89 standard behaviour and that's why this issue worries me.

            I'd be grateful if DBD::Informix and DBD::Ingres could check for this (if you
            support bind parameters).

            > > >I'll name the DBI attribute TrimBlanks unless anyone has a better idea.
            >
            > Maybe you want to call it ChopBlanks or RTrimBlanks. TrimBlanks kinda makes me
            > think of Oracle LTRIM and RTRIM which implies trimming will happen at both ends
            > of the string, which is a useful function to have. No?

            Yes, I was aware of the issue but couldn't think of a better name. I like
            ChopBlanks because of the association with chop in perl. Then again RTrimBlanks
            is even less ambiguous.

            What do other people think?

            : From: Henrik Tougaard <ht@...>
            :
            : > It believe it should default to off but I am (just) open to arguments.
            :
            : I would suggest that it should be controlled by ->{CompatMode}, ie.
            : we leave everything as it is for the existing oraperl/ingperl scripts) and
            : have the ned behaviour for the new DBD::Oracle, DBD::Ingres,
            : DBD::Informix, ... scripts.

            That's a very good idea. It give us more freedom.

            : (hey what about the existing DBD::Oracle
            : scripts that rely on the trailing blanks? I just don't know. :-)

            I don't expect to hear many complaints given the amount of times I've said
            the DBI may change. Anyone complaining will know what my reply will be! :-)


            So, to summarise, my current thinking is that we add an attribute which
            controls trimming of trailing spaces (ascii 32) from just char type fields.

            This attribute will default to true. Emulation interfaces should set the
            database handle attribute to match the interface they are emulating.

            Okay?

            All that's left to consider is the name.

            Tim.


            ------------------------------------------------------------------------------
            To unsubscribe from this list, please visit http://www.fugue.com/dbi.
            If you are without web access, or if you are having trouble with the web page,
            please send mail to dbi-request@.... Please try to use the web
            page first - it will take a long time for your request to be processed by hand.
            ------------------------------------------------------------------------------
          • Michal Jaegermann
            Message 5 of 15 , May 1, 1997
            View Source
            • 0 Attachment
              *** From dbi-users -- To unsubscribe, see the end of this message. ***

              Henrik Tougaard wrote:
              > >
              > I still haven't found a place where trailing
              > blanks are significant

              Missing trailing blanks will get you when you try to "select"
              on names from a field with a fixed width. Then keys which look
              outwardly the same will mean diffrent things depending on a number
              of trailing blanks present.

              > (and couldn't be added without problems)

              Earlier versions of DBD::Oracle had this bug that trailing blanks
              from submitted keys were vanishing. Very frustrating!

              I am not sure why all of sudden these "improvements". Perl is rather
              good at processing strings, and removing trailing blanks when you
              want/need that. In my, rather strong, opinion DBI/DBD interface
              **should not** perform any quiet modifications behind your back,
              intended or uninteded. You never know who, and why, may need data
              exactly in their original form.

              Michal


              ------------------------------------------------------------------------------
              To unsubscribe from this list, please visit http://www.fugue.com/dbi.
              If you are without web access, or if you are having trouble with the web page,
              please send mail to dbi-request@.... Please try to use the web
              page first - it will take a long time for your request to be processed by hand.
              ------------------------------------------------------------------------------
            • Tim Bunce
              ... Careful! All DBD::Oracle did was use varchar type for the placeholder. Oracle did the rest. ... My gut feel agrees with you but efficiency and portability
              Message 6 of 15 , May 1, 1997
              View Source
              • 0 Attachment
                *** From dbi-users -- To unsubscribe, see the end of this message. ***

                > From: Michal Jaegermann <michal@...>
                >
                > Henrik Tougaard wrote:
                > > >
                > > I still haven't found a place where trailing
                > > blanks are significant
                >
                > Missing trailing blanks will get you when you try to "select"
                > on names from a field with a fixed width. Then keys which look
                > outwardly the same will mean diffrent things depending on a number
                > of trailing blanks present.
                >
                > > (and couldn't be added without problems)
                >
                > Earlier versions of DBD::Oracle had this bug that trailing blanks
                > from submitted keys were vanishing. Very frustrating!

                Careful! All DBD::Oracle did was use varchar type for the placeholder.
                Oracle did the rest.

                > I am not sure why all of sudden these "improvements". Perl is rather
                > good at processing strings, and removing trailing blanks when you
                > want/need that. In my, rather strong, opinion DBI/DBD interface
                > **should not** perform any quiet modifications behind your back,
                > intended or uninteded. You never know who, and why, may need data
                > exactly in their original form.

                My gut feel agrees with you but efficiency and portability concerns
                make me worry.

                Either way, the attribute will help.

                Tim.


                ------------------------------------------------------------------------------
                To unsubscribe from this list, please visit http://www.fugue.com/dbi.
                If you are without web access, or if you are having trouble with the web page,
                please send mail to dbi-request@.... Please try to use the web
                page first - it will take a long time for your request to be processed by hand.
                ------------------------------------------------------------------------------
              • Stuart 'Zen' Bishop
                *** From dbi-users -- To unsubscribe, see the end of this message. *** ... For fixed length SQL strings of type CHAR(n), the JDBC drivers will perform
                Message 7 of 15 , May 1, 1997
                View Source
                • 0 Attachment
                  *** From dbi-users -- To unsubscribe, see the end of this message. ***

                  On Thu, 1 May 1997, Tim Bunce wrote:

                  > > >Out of interest does anyone know what ODBC and JDBC do on this issue?
                  >
                  > I'd still like to know that, if anyone knows.

                  >From JDBC spec 1.2, p28:

                  "For fixed length SQL strings of type CHAR(n), the JDBC drivers will
                  perform appropriate padding with spaces"

                  [...]

                  "When a String is sent to a CHAR(n) field, the driver and/or the database
                  will add any necessary padding spaces to the end of the String to bring
                  it up to length 'n'".

                  It may save a lot of work if the DBI implementers read over the JDBC
                  spec (if they havn't already). It was designed to be implementable
                  "on top of common SQL level API's, in particular ODBC". As Java
                  shares many of the same features as Perl (OO, variable length strings &
                  arrays etc.), most of the tough decisions may have already been made
                  for you. And perhaps the best feature is that if someone doesn't like
                  the DBI interface, you can blame it on someone else :-) Major
                  decisions would be deciding which methods are useless in Perl
                  (a lot conversion functions like toString and toNumber are needed in Java)
                  and if you want to have all return types as objects ($o->toDate) or
                  only some like Date as objects (DBI::toDate($v).

                  ___
                  // Zen (alias Stuart Bishop) Work: zen@...
                  // E N Senior Systems Contortionist Play: zen@...
                  //__ RMIT Business CSG WWW: http://www.bf.rmit.edu.au/~zen





                  ------------------------------------------------------------------------------
                  To unsubscribe from this list, please visit http://www.fugue.com/dbi.
                  If you are without web access, or if you are having trouble with the web page,
                  please send mail to dbi-request@.... Please try to use the web
                  page first - it will take a long time for your request to be processed by hand.
                  ------------------------------------------------------------------------------
                • descarte@hermetica.com
                  ... I think it might have been you....I don t recall putting something like that in myself. Although, it may have been in DBD::Oracle, so we can both blame
                  Message 8 of 15 , May 1, 1997
                  View Source
                  • 0 Attachment
                    *** From dbi-users -- To unsubscribe, see the end of this message. ***

                    > >> DBD::Informix takes the view that since the trailing blanks on a CHAR
                    > >> field (as opposed to a VARCHAR field) are added automatically by the
                    > >> database system, they can be removed when they are fetched because (a)
                    > >> that's normally what people want, and (b) they do not convey significant
                    > >> information.
                    > >
                    > >I think those are dangerous assumptions.
                    >
                    > Maybe, but I've not had anyone complain yet about that behaviour. I'm not
                    > even sure whether I put that in place or whether Alligator's code did it
                    > too.

                    I think it might have been you....I don't recall putting something like that
                    in myself. Although, it may have been in DBD::Oracle, so we can both blame
                    Tim. 8-)

                    > I absolutely agree about VARCHAR; if there are trailing blanks in VARCHAR
                    > data, then they are preserved. DBD::Informix only trims explicit CHAR data.
                    > It also doesn't touch BYTE and TEXT data (old-style blobs).

                    Well, from Oracle's standpoint, CHARs are fixed length data, which, if
                    you specify a string shorter than the length of the field, it'll automatically
                    pad it. If you specify a longer string blank-padded, it'll trim it. If you
                    specify something too long, it chops it. So, I'm for trimming, I think.
                    Trailing-blanks aren't significant in CHARs, and VARCHAR will preserve them.
                    That's what Oracle will do anyway. If you SELECT a CHAR, Oracle should
                    automatically trim the value?

                    > >I'll name the DBI attribute TrimBlanks unless anyone has a better idea.

                    Maybe you want to call it ChopBlanks or RTrimBlanks. TrimBlanks kinda makes me
                    think of Oracle LTRIM and RTRIM which implies trimming will happen at both ends
                    of the string, which is a useful function to have. No?

                    > Jonathan Leffler (johnl@...) #include <witticism.h>

                    A.

                    --
                    Alligator Descartes |
                    descarte@... | "Lobey est le petit garcon!" -- Bud Neill
                    http://www.hermetica.com |


                    ------------------------------------------------------------------------------
                    To unsubscribe from this list, please visit http://www.fugue.com/dbi.
                    If you are without web access, or if you are having trouble with the web page,
                    please send mail to dbi-request@.... Please try to use the web
                    page first - it will take a long time for your request to be processed by hand.
                    ------------------------------------------------------------------------------
                  Your message has been successfully submitted and would be delivered to recipients shortly.