Thread

  1. regression: select_views.sql

    Vadim Mikheev <vadim@sable.krasnoyarsk.su> — 1998-02-18T12:48:48Z

    I got different results for the second query 
    (SELECT * FROM iexit ORDER BY 1, 2;) when using -S 64 (on-disk sorting)
    and -S 8192 (in-memory).
    Could it be caused by this _wrong_ line in pg_operator.h:
    
    DATA(insert OID =  793 (  "<"      PGUID 0 b t f  602  602  701  ... path_n_lt ...
                                                                ^^^
                                  this is float8 but path_n_lt() returns bool...
    
    The same for all path_n_* funcs (may be others too)...
    
    Vadim
    
    
  2. Re: [HACKERS] regression: select_views.sql

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-02-24T02:57:49Z

    > I got different results for the second query
    > (SELECT * FROM iexit ORDER BY 1, 2;) when using -S 64 (on-disk sorting)
    > and -S 8192 (in-memory).
    > Could it be caused by this _wrong_ line in pg_operator.h:
    >
    > DATA(insert OID =  793 (  "<"      PGUID 0 b t f  602  602  701  ... path_n_lt ...
    >                                                             ^^^
    >                               this is float8 but path_n_lt() returns bool...
    >
    > The same for all path_n_* funcs (may be others too)...
    
    I'll fix this...
    
    
    
  3. Re: [HACKERS] regression: select_views.sql

    Vadim Mikheev <vadim@sable.krasnoyarsk.su> — 1998-02-24T03:39:57Z

    Thomas G. Lockhart wrote:
    > 
    > > DATA(insert OID =  793 (  "<"      PGUID 0 b t f  602  602  701  ... path_n_lt ...
    > >                                                             ^^^
    > >                               this is float8 but path_n_lt() returns bool...
    > >
    > > The same for all path_n_* funcs (may be others too)...
    > 
    > I'll fix this...
    
    Nice. There are other invalids:
    
    vac=> select oprname, oprcode from pg_operator where oprcanhash and oprname <> '=';
    oprname|oprcode     
    -------+------------
    ~=     |intervalsame
    ^^^^^^^^^^^^^^^^^^^^ ok, but others are not!
    <>     |intervalne  
    <      |intervallt  
    >      |intervalgt  
    <=     |intervalle  
    >=     |intervalge  
    (6 rows)
    
    (BTW, oprcanhash can be used to let know does operator mean EQUALity...
    I'd like to use this for subselects)
    
    Vadim
    
    
  4. Re: [HACKERS] regression: select_views.sql

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-02-24T04:16:49Z

    Vadim B. Mikheev wrote:
    
    > Thomas G. Lockhart wrote:
    > >
    > > > DATA(insert OID =  793 (  "<"      PGUID 0 b t f  602  602  701  ... path_n_lt ...
    > > >                                                             ^^^
    > > >                               this is float8 but path_n_lt() returns bool...
    > > >
    > > > The same for all path_n_* funcs (may be others too)...
    > >
    > > I'll fix this...
    >
    > Nice. There are other invalids:
    >
    > vac=> select oprname, oprcode from pg_operator where oprcanhash and oprname <> '=';
    > oprname|oprcode
    > -------+------------
    > ~=     |intervalsame
    > ^^^^^^^^^^^^^^^^^^^^ ok, but others are not!
    > <>     |intervalne
    > <      |intervallt
    > >      |intervalgt
    > <=     |intervalle
    > >=     |intervalge
    > (6 rows)
    
    Hmm. Those look like they support the "time interval" type, which I haven't been updating
    because it is based on abstime; I'm more interested in the wider-range/more-precise
    datetime-based stuff. I would think about rewriting the time interval routines, but
    assume it was used somewhere in the backend to support time travel. Don't know if it is
    still in there somewhere...
    
                                               - Tom
    
    
    
  5. Re: [HACKERS] regression: select_views.sql

    Vadim Mikheev <vadim@sable.krasnoyarsk.su> — 1998-02-24T04:26:09Z

    Thomas G. Lockhart wrote:
    > 
    > >
    > > vac=> select oprname, oprcode from pg_operator where oprcanhash and oprname <> '=';
    > > oprname|oprcode
    > > -------+------------
    > > ~=     |intervalsame
    > > ^^^^^^^^^^^^^^^^^^^^ ok, but others are not!
    > > <>     |intervalne
    > > <      |intervallt
    > > >      |intervalgt
    > > <=     |intervalle
    > > >=     |intervalge
    > > (6 rows)
    > 
    > Hmm. Those look like they support the "time interval" type, which I haven't been updating
    > because it is based on abstime; I'm more interested in the wider-range/more-precise
    > datetime-based stuff. I would think about rewriting the time interval routines, but
    > assume it was used somewhere in the backend to support time travel. Don't know if it is
    > still in there somewhere...
    
    I just say that all these <>, <, >, >=, <= must have FALSE in oprcanhash.
    Having TRUE for them is bug.
    
    Vadim