"Kevin Grittner" writes:
> Tom Lane wrote:
>> Here's a proposed patch, sans documentation as yet.
> I see you took the surgical approach -- only a cast from a record to
> a character string type is affected. I agree that will fix the
> complaints I've seen, and I imagine you're keeping the cha
Tom Lane wrote:
> Here's a proposed patch, sans documentation as yet.
I see you took the surgical approach -- only a cast from a record to
a character string type is affected. I agree that will fix the
complaints I've seen, and I imagine you're keeping the change narrow
to minimize the risk o
I wrote:
> Ah. No, that would still work after the change. The case that I'm
> proposing to break is using function-ish notation to invoke a cast
> from a composite type to some other type whose name you use as if it
> were a function. Even there, if you've created such a cast following
> the us
Merlin Moncure writes:
> On Thu, Nov 4, 2010 at 12:14 PM, Tom Lane wrote:
>> "Kevin Grittner" writes:
>>> Merlin Moncure wrote:
create type x as (a int, b int);
select f((1,2));
>> I think Merlin probably meant to write "select x((1,2))", but that
>> doesn't work out-of-the-box eithe
Tom Lane wrote:
> What would be affected is something like
>
> select text((1,2));
>
> which you'd now be forced to write as
>
> select (1,2)::text;
>
> (or you could use CAST notation; but not text(row) or row.text).
Right. As far as I'm aware, there are currently four ways t
On Thu, Nov 4, 2010 at 12:14 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Merlin Moncure wrote:
>>> Trying to understand real world cases that this would
>>> break...would the following now fail w/o explicit cast?
>>>
>>> create type x as (a int, b int);
>>> select f((1,2));
>
>> It already
"Kevin Grittner" writes:
> Merlin Moncure wrote:
>> Trying to understand real world cases that this would
>> break...would the following now fail w/o explicit cast?
>>
>> create type x as (a int, b int);
>> select f((1,2));
> It already does:
I think Merlin probably meant to write "select x((
Merlin Moncure wrote:
> Trying to understand real world cases that this would
> break...would the following now fail w/o explicit cast?
>
> create type x as (a int, b int);
> select f((1,2));
It already does:
test=# create type x as (a int, b int);
CREATE TYPE
test=# select f((1,2));
ERROR:
On Fri, Oct 29, 2010 at 4:12 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Robert Haas wrote:
I think if I had to pick a proposal, I'd say we should disable #2
for the specific case of casting a composite type to something
else.
>
>>> Well, then let's do that. It's not the ex
On Tue, Nov 2, 2010 at 4:34 PM, Kevin Grittner
wrote:
> Jon Nelson wrote:
>
>> If I saw this behavior ( a.b also meaning b(a) ) in another SQL
>> engine, I would consider it a thoroughly unintuitive wart
>
> I think the main reason it has been kept is the converse -- if you
> define a function "b
Jon Nelson wrote:
> If I saw this behavior ( a.b also meaning b(a) ) in another SQL
> engine, I would consider it a thoroughly unintuitive wart
I think the main reason it has been kept is the converse -- if you
define a function "b" which takes record "a" as its only parameter,
you have effect
On Fri, Oct 29, 2010 at 2:07 PM, Tom Lane wrote:
> [ please continue any further discussion in pgsql-bugs only ]
>
> "Kevin Grittner" writes:
>> Tom Lane wrote:
>>> BTW this seems pretty far off-topic for pgsql-performance.
>
>> It is once you understand what's happening. It was probably the 11
On Oct 29, 2010, at 5:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> Yeah, I think we're going to have to live with it, at least for 8.4. One
>> could make an argument that 9.0 is new enough we could get away with a small
>> behavior change to avoid a large amount of user confusion. But that
Robert Haas writes:
> Yeah, I think we're going to have to live with it, at least for 8.4. One
> could make an argument that 9.0 is new enough we could get away with a small
> behavior change to avoid a large amount of user confusion. But that may be a
> self-serving argument based on wanting
On Oct 29, 2010, at 4:21 PM, "Kevin Grittner"
wrote:
> Tom Lane wrote:
>> "Kevin Grittner" writes:
>>> Robert Haas wrote:
> I think if I had to pick a proposal, I'd say we should disable
> #2 for the specific case of casting a composite type to
> something else.
>>
Well, then
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Robert Haas wrote:
I think if I had to pick a proposal, I'd say we should disable
#2 for the specific case of casting a composite type to
something else.
>
>>> Well, then let's do that. It's not the exact fix I'd pick, but
>>> it's
"Kevin Grittner" writes:
> Robert Haas wrote:
>>> I think if I had to pick a proposal, I'd say we should disable #2
>>> for the specific case of casting a composite type to something
>>> else.
>> Well, then let's do that. It's not the exact fix I'd pick, but
>> it's clearly better than nothing
Robert Haas wrote:
>> 2. The notation t(x) will be taken to mean x::t if there's no
>> function t() taking x's type, but there is a cast from x's type
>> to t.
>> I think if I had to pick a proposal, I'd say we should disable #2
>> for the specific case of casting a composite type to something
On Fri, Oct 29, 2010 at 3:07 PM, Tom Lane wrote:
> [ please continue any further discussion in pgsql-bugs only ]
>
> "Kevin Grittner" writes:
>> Tom Lane wrote:
>>> BTW this seems pretty far off-topic for pgsql-performance.
>
>> It is once you understand what's happening. It was probably the 11
[ please continue any further discussion in pgsql-bugs only ]
"Kevin Grittner" writes:
> Tom Lane wrote:
>> BTW this seems pretty far off-topic for pgsql-performance.
> It is once you understand what's happening. It was probably the 11+
> minutes for the mistyped query run, versus the 28 ms w
20 matches
Mail list logo
