čt 19. 3. 2020 v 16:44 odesílatel Tom Lane napsal:
> I wrote:
> > Here's a pretty-nearly-final version of the patch.
> > In 0001 below, I've left it throwing an error for the case of all
> > ANYCOMPATIBLE inputs being unknown, but the documentation fails to
> > acknowledge that. 0002 below is a
I wrote:
> Here's a pretty-nearly-final version of the patch.
> In 0001 below, I've left it throwing an error for the case of all
> ANYCOMPATIBLE inputs being unknown, but the documentation fails to
> acknowledge that. 0002 below is a delta patch that switches to the
> other approach of resolving
Here's a pretty-nearly-final version of the patch.
In 0001 below, I've left it throwing an error for the case of all
ANYCOMPATIBLE inputs being unknown, but the documentation fails to
acknowledge that. 0002 below is a delta patch that switches to the
other approach of resolving as TEXT. I'm
st 18. 3. 2020 v 18:09 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > st 18. 3. 2020 v 17:54 odesílatel Tom Lane napsal:
> >> No, because if you've got that alongside foo2(anycompatible,
> >> anycompatible) then your queries will fail due to both functions
> >> matching anything
Pavel Stehule writes:
> st 18. 3. 2020 v 17:54 odesílatel Tom Lane napsal:
>> No, because if you've got that alongside foo2(anycompatible,
>> anycompatible) then your queries will fail due to both functions
>> matching anything that's promotable to text.
> It is working for anyelement
[ pokes
st 18. 3. 2020 v 17:54 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > st 18. 3. 2020 v 17:14 odesílatel Tom Lane napsal:
> >> However, it seems to me that this is inconsistent with the definition,
> >> namely that we resolve the common type the same way select_common_type()
> >> does,
Pavel Stehule writes:
> st 18. 3. 2020 v 17:14 odesílatel Tom Lane napsal:
>> However, it seems to me that this is inconsistent with the definition,
>> namely that we resolve the common type the same way select_common_type()
>> does, because select_common_type() will choose TEXT when given
st 18. 3. 2020 v 17:14 odesílatel Tom Lane napsal:
> So ... there is a definitional question here that doesn't seem to have
> been mentioned anywhere in the thread. For the traditional polymorphic
> types, we insist that at least one non-unknown input be supplied, thus
> you get
>
>
So ... there is a definitional question here that doesn't seem to have
been mentioned anywhere in the thread. For the traditional polymorphic
types, we insist that at least one non-unknown input be supplied, thus
you get
regression=# create function foo(anyelement, anyelement) returns bool
I wrote:
> The cfbot will be unhappy at this point, but I need to rebase the
> main patch again ...
And rebased. Still not quite happy about some of the details in
enforce_generic_type_consistency, and I've not looked at the test
cases or documentation at all. But this should make the cfbot
I wrote:
> Pavel Stehule writes:
>> There was a problem just with anyrange type. This last version looks
>> perfect.
> If you think that "matching polymorphic types" is too vague, I'm
> not sure there's much daylight between there and spelling it out
> in full as this latest patch does.
Pavel Stehule writes:
> ne 15. 3. 2020 v 17:48 odesílatel Tom Lane napsal:
>> Well, here's a version that does it like that, but personally I find these
>> messages too verbose and not an improvement on what I had before.
> There was a problem just with anyrange type. This last version looks
>
ne 15. 3. 2020 v 17:48 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > Tom Lane napsal:
> >> Yeah, that's what I said. But does it really add anything beyond the
> >> proposed text "A function returning a polymorphic type must have at
> least
> >> one matching polymorphic argument"?
Pavel Stehule writes:
> Tom Lane napsal:
>> Yeah, that's what I said. But does it really add anything beyond the
>> proposed text "A function returning a polymorphic type must have at least
>> one matching polymorphic argument"? I don't think it'd be terribly
>> helpful to say "A function
so 14. 3. 2020 v 14:26 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > pá 13. 3. 2020 v 23:42 odesílatel Tom Lane napsal:
> >> The reason that this might be controversial is that it forces a slightly
> >> less precise error detail message to be issued, since the call site
> that's
> >>
Pavel Stehule writes:
> pá 13. 3. 2020 v 23:42 odesílatel Tom Lane napsal:
>> The reason that this might be controversial is that it forces a slightly
>> less precise error detail message to be issued, since the call site that's
>> throwing the error doesn't know exactly which rule was being
pá 13. 3. 2020 v 23:42 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > [ anycompatible-types-20191127.patch ]
>
> I'm starting to review this patch seriously. I've found some bugs and
> things I didn't like, and the documentation certainly needs work, but
> I think I can get it to a
Pavel Stehule writes:
> [ anycompatible-types-20191127.patch ]
I'm starting to review this patch seriously. I've found some bugs and
things I didn't like, and the documentation certainly needs work, but
I think I can get it to a committable state before too much longer.
What I want to talk
po 25. 11. 2019 v 14:35 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Mon, Jun 17, 2019 at 05:31:40AM +0200, Pavel Stehule wrote:
> >
> > > I like anycompatible and anycompatiblearray.
> > >
> > > I'll update the patch
> > >
> >
> > and here it is
>
> Thanks for the patch! I've
> On Mon, Jun 17, 2019 at 05:31:40AM +0200, Pavel Stehule wrote:
>
> > I like anycompatible and anycompatiblearray.
> >
> > I'll update the patch
> >
>
> and here it is
Thanks for the patch! I've reviewed it a bit, and have a few small
commentaries:
* There are few traces of copy paste in
Hi
pá 14. 6. 2019 v 6:09 odesílatel Pavel Stehule
napsal:
>
>
> čt 13. 6. 2019 v 2:37 odesílatel Tom Lane napsal:
>
>> Greg Stark writes:
>> > The proposals I see above are "commontype", "supertype",
>> "anycommontype",
>> > and various abbreviations of those. I would humbly add
čt 13. 6. 2019 v 2:37 odesílatel Tom Lane napsal:
> Greg Stark writes:
> > The proposals I see above are "commontype", "supertype", "anycommontype",
> > and various abbreviations of those. I would humbly add "compatibletype".
> > Fwiw I kind of like commontype.
> > Alternately an argument could
Greg Stark writes:
> The proposals I see above are "commontype", "supertype", "anycommontype",
> and various abbreviations of those. I would humbly add "compatibletype".
> Fwiw I kind of like commontype.
> Alternately an argument could be made that length and typing convenience
> isn't really a
Hi
út 5. 3. 2019 v 18:37 odesílatel Pavel Stehule
napsal:
>
>
> út 5. 3. 2019 v 15:35 odesílatel Tom Lane napsal:
>
>> David Steele writes:
>> > This thread has been very quiet for a month. I agree with Andres [1]
>> > that we should push this to PG13.
>>
>> I think the main thing it's
út 5. 3. 2019 v 15:35 odesílatel Tom Lane napsal:
> David Steele writes:
> > This thread has been very quiet for a month. I agree with Andres [1]
> > that we should push this to PG13.
>
> I think the main thing it's blocked on is disagreement on what the
> type name should be, which is kind of
David Steele writes:
> This thread has been very quiet for a month. I agree with Andres [1]
> that we should push this to PG13.
I think the main thing it's blocked on is disagreement on what the
type name should be, which is kind of a silly thing to get blocked on,
but nonetheless it's
út 5. 3. 2019 v 14:38 odesílatel David Steele napsal:
> On 2/4/19 4:21 AM, Michael Paquier wrote:
> > On Wed, Jan 30, 2019 at 05:08:03PM +0100, Pavel Stehule wrote:
> >> maybe "supertype". It is one char shorter .. somewhere is term
> >> "supperclass, ..."
> >>
> >> In Czech language this term
On 2/4/19 4:21 AM, Michael Paquier wrote:
On Wed, Jan 30, 2019 at 05:08:03PM +0100, Pavel Stehule wrote:
maybe "supertype". It is one char shorter .. somewhere is term
"supperclass, ..."
In Czech language this term is short, "nadtyp", but probably it is not
acceptable :)
Moved to next CF.
On Wed, Jan 30, 2019 at 05:08:03PM +0100, Pavel Stehule wrote:
> maybe "supertype". It is one char shorter .. somewhere is term
> "supperclass, ..."
>
> In Czech language this term is short, "nadtyp", but probably it is not
> acceptable :)
Moved to next CF.
--
Michael
signature.asc
st 30. 1. 2019 v 17:00 odesílatel Pavel Stehule
napsal:
>
>
> po 28. 1. 2019 v 20:47 odesílatel Robert Haas
> napsal:
>
>> On Fri, Jan 25, 2019 at 7:21 PM Tom Lane wrote:
>> > Anyway I think the names need to be any-something.
>>
>> To me, that seems unnecessarily rigid. Not a bad idea if we
po 28. 1. 2019 v 20:47 odesílatel Robert Haas
napsal:
> On Fri, Jan 25, 2019 at 7:21 PM Tom Lane wrote:
> > Anyway I think the names need to be any-something.
>
> To me, that seems unnecessarily rigid. Not a bad idea if we can come
> up with something that is otherwise acceptable. But all of
On Fri, Jan 25, 2019 at 7:21 PM Tom Lane wrote:
> Anyway I think the names need to be any-something.
To me, that seems unnecessarily rigid. Not a bad idea if we can come
up with something that is otherwise acceptable. But all of your
suggestions sound worse than Pavel's proposal, so...
--
>
>
>
>> My second problem with this proposal is that it simply ignores
>> the naming precedent of the existing polymorphic types. We have
>> a convention that polymorphic types are named "any-something",
>> and I do not think we should just toss that overboard. Moreover,
>> if we do end up
so 26. 1. 2019 v 1:20 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > Four years ago I proposed implicit casting to common type of arguments
> with
> > anyelement type.
> >
> https://www.postgresql.org/message-id/CAFj8pRCZVo_xoW0cfxt%3DmmgjXKBgr3Gm1VMGL_zx9wDRHmm6Cw%40mail.gmail.com
> >
Pavel Stehule writes:
> Four years ago I proposed implicit casting to common type of arguments with
> anyelement type.
> https://www.postgresql.org/message-id/CAFj8pRCZVo_xoW0cfxt%3DmmgjXKBgr3Gm1VMGL_zx9wDRHmm6Cw%40mail.gmail.com
> My proposal was rejected, because it introduce compatibility
Hi,
the possibility to use polymorphic types is a specific interesting
PostgreSQL feature. The polymorphic types allows to use almost all types,
but when some type is selected, then this type is required strictly without
possibility to use some implicit casting.
So if I have a fx(anyelement,
36 matches
Mail list logo
