From: | "Thomas G(dot) Lockhart" <lockhart(at)alumnus(dot)caltech(dot)edu> |
---|---|
To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | hackers(at)postgreSQL(dot)org |
Subject: | Re: Recent updates |
Date: | 1998-07-15 13:15:41 |
Message-ID: | 35ACAB7D.9B5F1793@apop-server.alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > Yeah, it's sticky. Where in the code does the sorting get set up?
> See optimizer/prep/prepunion.c::plan_union_queries(). You will see me
> calling transformSortClause() from there to set up a query using
> UNION/UNION ALL. I think that is where the problem is happening.
> Whatever you did in the parser to get these types converted is not in
> that function. Can you check into it? Should I be doing that in
> another place. I am unsure, but it looks like the best place for it.
OK, made a change to transformSortClause() called from
plan_union_queries():
postgres=> select null union select null;
?column?
--------
(1 row)
postgres=> select null union select null union all select null;
?column?
--------
(2 rows)
I decided to use the int4 sorting routines when the type is
"InvalidOid", the type apparently assigned to null constants. The sort
routines probably don't get called anyway since everything is a null,
and if they did the "pass by value" int4 routines are probably safest.
Will continue testing, and need to look into this still:
postgres=> select 1 union select null union all select null;
Backend message type 0x44 arrived while idle
...
- Tom
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1998-07-15 14:42:00 | Re: [INTERFACES][HACKERS] atttypmod now 32 bits, interface change |
Previous Message | Herouth Maoz | 1998-07-15 10:04:26 | Re: [INTERFACES][HACKERS] atttypmod now 32 bits, interface change |