On 2024-May-06, Erik Wienhold wrote:
> On 2024-05-06 10:59 +0200, Alvaro Herrera wrote:
> > By the way, this neighboring sentence is a bit awkward
> >
> > " It must be ... or a type for which there is a cast from json to that
> > type."
> Or maybe just
> "[...] or any type that can be cast
On 2024-05-06 10:59 +0200, Alvaro Herrera wrote:
> By the way, this neighboring sentence is a bit awkward
>
> " It must be ... or a type for which there is a cast from json to that type."
>
> Would it be better to say
> " It must be ... or a type to which a cast from json exists."
> ?
Yeah, th
On 06.05.24 10:53, Alvaro Herrera wrote:
On 2024-May-05, David Rowley wrote:
On Sun, 5 May 2024 at 12:41, Erik Wienhold wrote:
So, I think we should either remove that one nchar instance (because it
doesn't add any real value) or document it properly. The attached patch
does the latter.
It
By the way, this neighboring sentence is a bit awkward
" It must be ... or a type for which there is a cast from json to that type."
Would it be better to say
" It must be ... or a type to which a cast from json exists."
?
--
Álvaro Herrera 48°01'N 7°57'E — https://www.Enterpr
On 2024-May-05, David Rowley wrote:
> On Sun, 5 May 2024 at 12:41, Erik Wienhold wrote:
> > So, I think we should either remove that one nchar instance (because it
> > doesn't add any real value) or document it properly. The attached patch
> > does the latter.
>
> It seems easier to do the form
On Sun, 5 May 2024 at 12:41, Erik Wienhold wrote:
> So, I think we should either remove that one nchar instance (because it
> doesn't add any real value) or document it properly. The attached patch
> does the latter.
It seems easier to do the former, that way we don't need to reconsider
Peter's
While studying the parser, I noticed that we support nchar and the n''
literal. But both concepts are undocumented. That may be intentional
because nchar is just an alias for char and because all our string types
are multibyte and therefore essentially national character strings.
I was looking t
