On Thu, Apr 23, 2015 at 1:49 AM, David G. Johnston
david.g.johns...@gmail.com wrote:
Reading and writing all this I'm convinced you have gotten the idea in your
mind an expectation of equivalency and consistency where there really is
little or none from an overall design perspective. And none
On 4/23/15 5:07 AM, Kyotaro HORIGUCHI wrote:
This is because parsing of UNION immediately converts constants
of unknown type in the UNION's both arms to text so the top level
select won't be bothered by this problem. But the problematic
query doesn't have appropriate timing to do that until the
On Thursday, April 23, 2015, Jeff Davis pg...@j-davis.com wrote:
On Thu, Apr 23, 2015 at 1:49 AM, David G. Johnston
david.g.johns...@gmail.com javascript:; wrote:
Reading and writing all this I'm convinced you have gotten the idea in
your
mind an expectation of equivalency and consistency
Hello,
At Thu, 23 Apr 2015 14:49:29 -0500, Jim Nasby jim.na...@bluetreble.com wrote
in 55394cc9.5050...@bluetreble.com
On 4/23/15 5:07 AM, Kyotaro HORIGUCHI wrote:
This is because parsing of UNION immediately converts constants
of unknown type in the UNION's both arms to text so the top
On Wed, 2015-04-22 at 20:35 -0700, David G. Johnston wrote:
But the fact that column b has the data type unknown is only a
warning - not an error.
I get an error:
postgres=# SELECT ' '::text = 'a';
?column?
--
f
(1 row)
postgres=# SELECT a=b FROM (SELECT ''::text, ' ') x(a,b);
Sorry, the patch had obvious bug..
-+
Int32GetDatum(inputTypeMod),
++
Int32GetDatum(targetTypeMod),
regards,
Hello, I
On Thu, Apr 23, 2015 at 1:35 AM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
Very sorry for the trash..
===
Now I found a comment at just where I patched,
* XXX if the typinput function is not immutable, we really ought to
* postpone evaluation of the function call until
On Thu, Apr 23, 2015 at 1:07 AM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
Hello, I think this is a bug.
The core of this problem is that coerce_type() fails for Var of
type UNKNOWNOID.
The comment for the function says that,
* The caller should already have determined
Hello, I think this is a bug.
The core of this problem is that coerce_type() fails for Var of
type UNKNOWNOID.
The comment for the function says that,
* The caller should already have determined that the coercion is possible;
* see can_coerce_type.
But can_coerce_type() should say it's
On Wednesday, April 22, 2015, Jeff Davis pg...@j-davis.com wrote:
On Wed, 2015-04-22 at 20:35 -0700, David G. Johnston wrote:
But the fact that column b has the data type unknown is only a
warning - not an error.
I get an error:
postgres=# SELECT ' '::text = 'a';
?column?
Very sorry for the trash..
===
Now I found a comment at just where I patched,
* XXX if the typinput function is not immutable, we really ought to
* postpone evaluation of the function call until runtime. But there
* is no way to represent a typinput function call as an expression
* tree,
On Thu, Apr 23, 2015 at 1:49 AM, David G. Johnston
david.g.johns...@gmail.com wrote:
On Wednesday, April 22, 2015, Jeff Davis pg...@j-davis.com wrote:
On Wed, 2015-04-22 at 20:35 -0700, David G. Johnston wrote:
My gut reaction is if you feel strongly enough to add some additional
Now I found a comment at just where I patched,
* XXX if the typinput function is not immutable, we really ought to
* postpone evaluation of the function call until runtime. But there
* is no way to represent a typinput function call as an expression
* tree, because C-string values are not
Hello,
Very sorry for the trash..
===
Now I found a comment at just where I patched,
* XXX if the typinput function is not immutable, we really ought to
* postpone evaluation of the function call until runtime. But there
* is no way to represent a typinput function call as
Hello,
Hello, I think this is a bug.
The core of this problem is that coerce_type() fails for Var of
type UNKNOWNOID.
The comment for the function says that,
* The caller should already have determined that the coercion is
possible;
* see can_coerce_type.
But
Moving thread to -hackers.
On Wed, Apr 8, 2015 at 11:18 PM, Jeff Davis pg...@j-davis.com wrote:
That example was just for illustration. My other example didn't require
creating a table at all:
SELECT a=b FROM (SELECT ''::text, ' ') x(a,b);
it's fine with me if we want that to fail, but I
My apologies if much of this is already assumed knowledge by most
-hackers...I'm trying to learn from observation instead of, largely,
reading code in a foreign language.
On Wed, Apr 22, 2015 at 6:40 PM, Jeff Davis pg...@j-davis.com wrote:
Moving thread to -hackers.
On Wed, Apr 8, 2015 at
17 matches
Mail list logo
