On Feb 21, 2024, at 11:54 AM, David Wheeler wrote:
> Merged this change into the [to_regtypemod
> patch](https://commitfest.postgresql.org/47/4807/), which has exactly the
> same issue.
>
> The new status of this patch is: Needs review
Bah, withdrawn.
D
Merged this change into the [to_regtypemod
patch](https://commitfest.postgresql.org/47/4807/), which has exactly the same
issue.
The new status of this patch is: Needs review
On Feb 5, 2024, at 09:01, David E. Wheeler wrote:
> Ah, thank you. Updated patch attached.
I’ve moved this patch into the to_regtype patch thread[1], since it exhibits
the same behavior.
Best,
David
[1]
On Feb 4, 2024, at 19:11, Erik Wienhold wrote:
> Here "extracted names" should be "extracted name" (singular).
> Otherwise, the text looks good.
Ah, thank you. Updated patch attached.
Best,
David
v2-0001-Update-to_regtype-docs-regarding-error-condition.patch
Description: Binary data
On 2024-02-04 20:20 +0100, David E. Wheeler wrote:
> On Feb 2, 2024, at 15:33, David E. Wheeler wrote:
>
> > Anyway, I’m happy to submit a documentation patch along the lines you
> > suggested.
>
> How’s this?
>
> --- a/doc/src/sgml/func.sgml
> +++ b/doc/src/sgml/func.sgml
> @@ -25460,11
On Feb 2, 2024, at 15:33, David E. Wheeler wrote:
> Anyway, I’m happy to submit a documentation patch along the lines you
> suggested.
How’s this?
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25460,11 +25460,12 @@ SELECT collation for ('foo' COLLATE "de_DE");
regtype
On Feb 2, 2024, at 3:23 PM, David G. Johnston
wrote:
> Seems like most just want to leave well enough alone and deal with the rare
> question for oddball input on the mailing list. If you are interested enough
> to come back after 4 months I'd suggest you write up and submit a patch. I'm
>
On Mon, Jan 29, 2024 at 8:45 AM David E. Wheeler
wrote:
> Hey there, coming back to this. I poked at the logs in the master branch
> and saw no mention of to_regtype; did I miss it?
>
With no feedback regarding my final suggestion I lost interest in it and
never produced a patch.
> On Sep 17,
Hey there, coming back to this. I poked at the logs in the master branch and
saw no mention of to_regtype; did I miss it?
On Sep 17, 2023, at 10:58 PM, David G. Johnston
wrote:
> Parses a string of text, extracts a potential type name from it, and
> translates that name into an OID. Failure
On Sunday, September 17, 2023, Chapman Flack wrote:
>
> In this one, both identifiers are part of the type name, and the
> separator a little more flamboyant.
>
> select to_regtype('character /* hi!
> am I part of the type name? /* what, me too? */ ok! */ -- huh!
> varying');
> to_regtype
>
On 2023-09-17 21:58, David G. Johnston wrote:
ambiguity possible when doing that though:
create type "interval second" as (x int, y int);
select to_regtype('interval second'); --> interval
Not ambiguity really: that composite type you just made was named
with a single , which is one token.
On Sun, Sep 17, 2023 at 6:25 PM Chapman Flack wrote:
> On 2023-09-17 20:58, David G. Johnston wrote:
> > Put differently, there is no syntax involved when the value being
> > provided
> > is the text literal name of a type as it is stored in pg_type.typname,
> > so
> > the presence of a syntax
On 2023-09-17 20:58, David G. Johnston wrote:
Put differently, there is no syntax involved when the value being
provided
is the text literal name of a type as it is stored in pg_type.typname,
so
the presence of a syntax error is wrong.
Well, the situation is a little weirder than that,
On Sun, Sep 17, 2023 at 5:34 PM Erik Wienhold wrote:
> On 18/09/2023 00:57 CEST Vik Fearing wrote:
>
> > On 9/18/23 00:41, Erik Wienhold wrote:
> > > On 18/09/2023 00:13 CEST David E. Wheeler
> wrote:
> > >
> > >> david=# select to_regtype('inteval second');
> > >> ERROR: syntax error at or
On Mon, 2023-09-18 at 00:57 +0200, Vik Fearing wrote:
> On 9/18/23 00:41, Erik Wienhold wrote:
> > On 18/09/2023 00:13 CEST David E. Wheeler wrote:
> > > The docs for `to_regtype()` say, “this function will return NULL rather
> > > than
> > > throwing an error if the name is not found.” And it’s
On Sep 17, 2023, at 19:28, Tom Lane wrote:
>> No, that is precisely the point. The result should be null instead of
>> an error.
>
> Yeah, ideally so, but the cost/benefit of making it happen seems
> pretty unattractive for now. See the soft-errors thread at [1],
> particularly [2] (but
On 18/09/2023 00:57 CEST Vik Fearing wrote:
> On 9/18/23 00:41, Erik Wienhold wrote:
> > On 18/09/2023 00:13 CEST David E. Wheeler wrote:
> >
> >> david=# select to_regtype('inteval second');
> >> ERROR: syntax error at or near "second"
> >> LINE 1: select to_regtype('inteval second');
> >>
Vik Fearing writes:
> No, that is precisely the point. The result should be null instead of
> an error.
Yeah, ideally so, but the cost/benefit of making it happen seems
pretty unattractive for now. See the soft-errors thread at [1],
particularly [2] (but searching in that thread for
On 9/18/23 00:41, Erik Wienhold wrote:
On 18/09/2023 00:13 CEST David E. Wheeler wrote:
The docs for `to_regtype()` say, “this function will return NULL rather than
throwing an error if the name is not found.” And it’s true most of the time:
david=# select to_regtype('foo'),
On 18/09/2023 00:13 CEST David E. Wheeler wrote:
> The docs for `to_regtype()` say, “this function will return NULL rather than
> throwing an error if the name is not found.” And it’s true most of the time:
>
> david=# select to_regtype('foo'), to_regtype('clam');
> to_regtype | to_regtype
>
The docs for `to_regtype()` say, “this function will return NULL rather than
throwing an error if the name is not found.” And it’s true most of the time:
david=# select to_regtype('foo'), to_regtype('clam');
to_regtype | to_regtype
+
[null] | [null]
But not others:
21 matches
Mail list logo
