Re: Recent updates

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

In response to

Responses

Browse pgsql-hackers by date

  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