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 (pgsql-patches@pos
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 fix
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 n
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 u
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
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 on
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_test
"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 hash
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 e
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...
> contr
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
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!
> P
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
>> sca
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 m
"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 ar
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?
>
convert_nu
"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 (pgsql
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:
> 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:
http://www.postgresql.org/docs/8.3
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 expecte
"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:
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
>
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
>
"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 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 l
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 l
26 matches
Mail list logo
