From: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Chris Albertson <chris(at)topdog(dot)pas1(dot)logicon(dot)com> |
Cc: | pgsql-hackers(at)hub(dot)org |
Subject: | Re: [HACKERS] Error in parser with UNIONS. |
Date: | 1998-05-22 01:26:03 |
Message-ID: | 3564D42B.1A9A9C0B@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I think I may have uncovered an error in the parser. The
> following is the simplest example that shows the problem.
> Maybe a counter needs to be reset by 'union' or checked
> after select not statement. I would like to use this syntax
> in my libpq program. Is this a bug? Is it already known?
Not already known, and it is a feature for now. I _should_ be able to
get it to work in v6.4, since I have already made changes elsewhere to
do a better job of guessing types in underspecified queries.
For example, in v6.3.2 the following query does not work:
postgres=> select 'a' || 'b' as "Concat";
Concat
------
ab
(1 row)
The underlying reason for the problem is Postgres' conservative approach
to typing and type coersion. I've made changes to make it a bit more
thorough in its matching attempts, and will look at this case soon.
> Would someone please e-mail me the syntax for the
> "explicit cast" the system wants
postgres=> select text 'a' as X
postgres-> union
postgres-> select text 'b';
x
-
a
b
(2 rows)
Note that this is the SQL92-style of specification; you can also use
"'a'::text" rather than "text 'a'". This example was run on something
similar to the current development source tree, but I would expect
v6.3.2 to behave the same way.
- Tom
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1998-05-22 03:38:08 | Re: [HACKERS] Error in parser with UNIONS. |
Previous Message | Tom Lane | 1998-05-21 23:13:35 | Time to fix libpgtcl for async NOTIFY |