Hello,
At Thu, 23 Apr 2015 14:49:29 -0500, Jim Nasby 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 level
> > select won'
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
f
On Thursday, April 23, 2015, Jeff Davis wrote:
> On Thu, Apr 23, 2015 at 1:49 AM, David G. Johnston
> > 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
On Thu, Apr 23, 2015 at 1:49 AM, David G. Johnston
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 insofar as
> would merit
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
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
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 det
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 c
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 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
>> > document
On Wednesday, April 22, 2015, Jeff Davis 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
> * tr
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
Sorry, the patch had obvious bug..
-+
Int32GetDatum(inputTypeMod),
++
Int32GetDatum(targetTypeMod),
regards,
> Hello, I
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 poss
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(
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 wrote:
> Moving thread to -hackers.
>
> On Wed, Apr 8, 2015 at 11:18 PM, Jeff Dav
Moving thread to -hackers.
On Wed, Apr 8, 2015 at 11:18 PM, Jeff Davis 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 don't think
17 matches
Mail list logo
