On 09/20/2013 08:38 AM, Kevin Grittner wrote:
> Did you look at the record_eq and record_cmp functions which exist
> before this patch? Is there a reason we should do it one way for the
> default operators and another way for this alternative?
> Do you think we should change record_eq and record_cmp to do things
> the way you suggest?
I think the record_eq and record_cmp functions would be better if they
shared code as well, but I don't think changing that should be part of
this patch, you aren't otherwise touching those functions. I know some
people dislike code that is switch based and prefer duplication, my
preference is to avoid duplication.
This seems like a bad idea to me. I don't like that I get a type comparison
error only sometimes based on the values of the data in the column. If I'm
a user testing code that compares two records with this operator and I test my
query with 1 value pair then and it works then I'd naively expect to get a
true or false on all other value sets of the same record type.
> Again, this is a result of following the precedent set by the
> existing record comparison operators.
>
> test=# create table r1 (c1 int, c2 int);
> CREATE TABLE
> test=# create table r2 (c1 int, c2 int, c3 int);
> CREATE TABLE
> test=# insert into r1 values (1, 2);
> INSERT 0 1
> test=# insert into r2 values (3, 4, 5);
> INSERT 0 1
> test=# select * from r1 join r2 on r1 < r2;
> c1 | c2 | c1 | c2 | c3
> ----+----+----+----+----
> 1 | 2 | 3 | 4 | 5
> (1 row)
>
> test=# update r1 set c1 = 3, c2 = 4;
> UPDATE 1
> test=# select * from r1 join r2 on r1 < r2;
> ERROR: cannot compare record types with different numbers of columns
>
> Would be in favor of forcing a change to the record comparison
> operators which have been in use for years? If not, is there a
> good reason to have them behave differently in this regard?
>
> --
I hadn't picked up on that you copied that part of the behaviour from
the existing comparison operators.
No we would need a really good reason for changing the behaviour of the
comparison operators and I don't think we have that. I agree that the
binary identical operators should behave similarly to the existing
comparison operators and error out on the column number mismatch after
comparing the columns that are present in both.
Steve
> Kevin Grittner
> EDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
