Skip site navigation (1) Skip section navigation (2)

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-14 04:14:58
Message-ID: 35AADB42.BD4890DA@apop-server.alumni.caltech.edu (view raw or flat)
Thread:
Lists: pgsql-hackers
> Good.  I assume UNION NULL is still an issue one of us needs to fix.

OK, I just committed changes to parse_clause.c which fix the most
obvious "UNION SELECT NULL" problems:

postgres=> select 1 union select null;
?column?
--------
       1

(2 rows)

Other permutations work too. The code also gets the types right if there
are multiple UNION clauses (remember the type of the result should be
the same as the type of the first clause in the UNION):

postgres=> select 1.1 as "float" union select NULL
postgres-> union select 2 union select 3.3;
float
-----
  1.1      <--- (this value determined the types)
    2      <--- (this was an int after a null)
  3.3      <--- (this double came after an int)
           <--- (null is here)
(4 rows)

In testing I found at least one remaining case with problems. It
involves a UNION ALL in clauses other than the first:

postgres=> select 1 union select 2 union all select null;
Backend message type 0x44 arrived while idle
pqReadData() -- backend closed the channel unexpectedly.
 This probably means the backend terminated abnormally before or while 
 processing the request.
We have lost the connection to the backend, so further processing is
 impossible.  Terminating.

At the same time, the backend printed the following:

Too Large Allocation Request("!(0 < (size)
 && (size) <= (0xfffffff)):size=-2 [0xfffffffe]",
 File: "mcxt.c", Line: 228)
 !(0 < (size) && (size) <= (0xfffffff)) (0)

Do you want to look at this Bruce? I haven't looked at it yet, but think
it might be deeper into the backend than the parser (haven't run into
mcxt.c before).

I am testing on a Friday's version of the cvs tree.

                           - Tom

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 1998-07-14 04:35:11
Subject: Re: Recent updates
Previous:From: Brandon IbachDate: 1998-07-14 03:39:25
Subject: Re: [HACKERS] atttypmod now 32 bits, interface change

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group