Hello all,
Just wanted to let everyone know I have committed this patch to the
PgFoundry uint project.
I have also updated the commit-fest wiki with this status.
Thanks to everyone (especially Jaime) for the feedback and reviews.
- Ryan
--
Sent via pgsql-patches mailing list
On Mon, Sep 15, 2008 at 9:45 PM, Ryan Bradetich [EMAIL PROTECTED] wrote:
I have the code and regression tests updated to solve the problems you
initially
discovered. After code reading, stepping through with the debugger, and
help from RhodiumToad on irc I was able to implement new restrict
Hello Jaime,
i'm still seeing the failures in the copy commands (the ones about the paths)
I just tested this on a different machine (to get it away from my
development environment)
I was able to duplicate the failures. It looks like I need to update
the expected/ files as well.
I will get
On 9/15/08, Ryan Bradetich [EMAIL PROTECTED] wrote:
Hello Jaime,
I have the code and regression tests updated to solve the problems you
initially
discovered.
great, i will test during this week...
--
regards,
Jaime Casanova
Soporte y capacitación de PostgreSQL
AsesorÃa y desarrollo de
Message Resend.
I forgot to spit the attachments so they did not make it through the list.
Patch 1 of 2 : Base uint type.
Patch 2 of 2 : Regression tests.
- Ryan
On Mon, Sep 15, 2008 at 8:13 AM, Ryan Bradetich [EMAIL PROTECTED] wrote:
Hello Jaime,
I have the code and regression tests
Hello Jaime,
It is taking longer than I expected to implement the scalarltsel and
scalargtsel functions for the unsigned integer data type.
I am still working on this solution and hope to have an updated patch
later this week (or over the weekend at the latest).
Just wanted to keep you updated
Hello Jaime,
Thank you for the test cases!
mmm... i rebuild my test env and it works for me this time... until i
execute an analyze. I guess autovacuum executed an auto analyze last
time...
I am able to duplicate the error you saw in the uint_test2.sql.
I am assuming you are seeing this
Ryan Bradetich [EMAIL PROTECTED] writes:
I am assuming you are seeing this error in the uint_test1.sql:
ERROR: could not find hash function for hash operator 16524
I can bypass the error in uint_test1.sql by disabling the hash joins.
I am going to dig in and figure out why the hashjoin
Hello Tom,
On Tue, Sep 9, 2008 at 5:11 AM, Tom Lane [EMAIL PROTECTED] wrote:
Ryan Bradetich [EMAIL PROTECTED] writes:
I am assuming you are seeing this error in the uint_test1.sql:
ERROR: could not find hash function for hash operator 16524
I can bypass the error in uint_test1.sql by
Hello Jamie and Tom.
Thank you very much for the feedback and reviews. I will attempt to
answer all the questions I found in this thread in this one email. If I
miss any questions, let me know and I will answer it :)
Jamie: Thanks for the feedback on missing comments. I will go back
and add
On Mon, Sep 8, 2008 at 1:14 AM, Ryan Bradetich [EMAIL PROTECTED] wrote:
If you read the comments around that stuff it leaves quite a lot to be
desired, but I don't really have better ideas at the moment. The best
near-term solution for the uint module is probably not to rely on
Hello Jaime,
the same problem happens in joins, unions, hash, etc... so you have to
look at those functions as well
Great! Added to the list to check. I am planning to build regression tests
for these types to catch these errors in the future. Thanks again for your
testing and review!
PS:
Hello Jaime,
why i need the cast in this case? even if the cast is really necesary
(the message seems realy ugly)
contrib_regression=# select * from t1 where f1 35;
ERROR: unsupported type: 16486
contrib_regression=# select * from t1 where f1 35::uint4;
f1
-
36
37
38
Can
On Mon, Sep 8, 2008 at 10:08 PM, Ryan Bradetich [EMAIL PROTECTED] wrote:
Can you send me the test case that generates this error?
My regression tests do not include a table t1 so I was not able
to reproduce this error directly.
yeah! that table is mine! here are the scripts...
On Sat, Sep 6, 2008 at 3:41 PM, Jaime Casanova
[EMAIL PROTECTED] wrote:
i still have to make some more test...
why i need the cast in this case? even if the cast is really necesary
(the message seems realy ugly)
contrib_regression=# select * from t1 where f1 35;
ERROR: unsupported type:
Jaime Casanova [EMAIL PROTECTED] writes:
contrib_regression=# select * from t1 where f1 35;
ERROR: unsupported type: 16486
That obviously isn't supposed to happen. Where's it coming from
exactly?
regards, tom lane
--
Sent via pgsql-patches mailing list
On Sun, Sep 7, 2008 at 2:41 AM, Tom Lane [EMAIL PROTECTED] wrote:
Jaime Casanova [EMAIL PROTECTED] writes:
contrib_regression=# select * from t1 where f1 35;
ERROR: unsupported type: 16486
That obviously isn't supposed to happen. Where's it coming from
exactly?
Jaime Casanova [EMAIL PROTECTED] writes:
On Sun, Sep 7, 2008 at 2:41 AM, Tom Lane [EMAIL PROTECTED] wrote:
That obviously isn't supposed to happen. Where's it coming from
exactly?
convert_numeric_to_scalar() in src/backend/utils/adt/selfuncs.c
the problem seems to be that we are asking for
On Sun, Aug 31, 2008 at 3:35 PM, Ryan Bradetich [EMAIL PROTECTED] wrote:
Hello all,
a few comments.
- i think you have to add some more comments in uint.c file and maybe
a header indicating this is part of the postgresql project or that is
intended to use with postgres or something of the like
Jaime Casanova [EMAIL PROTECTED] writes:
seems there is something wrong in the unlikely macro (i'm using GCC
4.2.3 in Ubuntu 4.2.3-2ubuntu7 with amd64)
postgres=# select -256::uint1;
ERROR: uint1 out of range
No, that's just because this is parsed as -(256::uint1)
On Sat, Sep 6, 2008 at 3:57 PM, Tom Lane [EMAIL PROTECTED] wrote:
Jaime Casanova [EMAIL PROTECTED] writes:
seems there is something wrong in the unlikely macro (i'm using GCC
4.2.3 in Ubuntu 4.2.3-2ubuntu7 with amd64)
postgres=# select -256::uint1;
ERROR: uint1 out of range
No, that's
On Sat, Sep 6, 2008 at 3:57 PM, Tom Lane [EMAIL PROTECTED] wrote:
Jaime Casanova [EMAIL PROTECTED] writes:
seems there is something wrong in the unlikely macro (i'm using GCC
4.2.3 in Ubuntu 4.2.3-2ubuntu7 with amd64)
postgres=# select -256::uint1;
ERROR: uint1 out of range
No, that's
Jaime Casanova [EMAIL PROTECTED] writes:
On Sat, Sep 6, 2008 at 3:57 PM, Tom Lane [EMAIL PROTECTED] wrote:
postgres=# select -256::uint1;
ERROR: uint1 out of range
No, that's just because this is parsed as -(256::uint1)
actually, i thought that case is right but the -255::uint1 returning
On Sat, Sep 6, 2008 at 7:10 PM, Tom Lane [EMAIL PROTECTED] wrote:
Now, if (-255)::uint1 fails to throw error, that would be a bug IMHO.
Casting any negative value to uint ought to fail, no?
then the patch is right but it seems to me like that is broking the
law of less surprise i expected
Jaime Casanova [EMAIL PROTECTED] writes:
then the patch is right but it seems to me like that is broking the
law of less surprise i expected -2::uint1 to be equivalent to
(-2)::uint1 that should be at least documented, no?
See the precedence table here:
Hello all,
I have attempted to send this email 3 times over the last 24 hours.
I am not sure what is blocking it, so I am going to break it up into two
parts:
uint-base.tar.bz2 -- The core of the unsigned integer type.
uint-tests.tar.bz2 -- The regression tests.
I am suspecting a size
26 matches
Mail list logo
