Re: Index creation

Your statement seems obvious to me. But what I see doesn't seem like a conscious choice. It turns out that it is better to have a lighter general-purpose index than to strive to create a target covering index for a certain kind of operation. DROP INDEX IF EXISTS

Re: A error happend when I am clone the git repository

Adrian Klaver writes: > On 6/19/22 20:33, Wen Yi wrote: >> |[beginnerc@fedora Research]$ git clone >> ||https://git.postgresql.org/git/postgresql.git >> | >> |Cloning into 'postgresql'...| >> |remote: Enumerating objects: 30747, done.| >> |remote:

Re: A error happend when I am clone the git repository

On 6/19/22 20:33, Wen Yi wrote: When I reinstall my system,I clone the postgresql repository,but there's something wrong. The console print as these: |[beginnerc@fedora Research]$ git clone ||https://git.postgresql.org/git/postgresql.git |

A error happend when I am clone the git repository

When I reinstall my system,I clone the postgresql repository,but there's something wrong. The console print as these: [beginnerc@fedora Research]$ git clone https://git.postgresql.org/git/postgresql.git Cloning into 'postgresql'... remote: Enumerating objects: 30747, done. remote: Counting

Re: '{"x": 42, "y": null}'::jsonb != '{"x": 42}'::jsonb ... Really?

> sham...@gmx.net wrote: > >> b...@yugabyte.com wrote: >> >> Am I missing a use case where an object with a key-value pair with a JSON >> null value is meaningfully different from one where the key is simply absent? > > It seems the JSON specification doesn't actually define equality. But the

Re: Outer joins and NULLs (old subject "ERROR: failed to find conversion function from key_vals_nn to record[]")

On Sun, Jun 19, 2022 at 2:31 PM Bryn Llewellyn wrote: > It would be foolish, therefore, to define the target table for > "insert-select" using "CTAS where false". > SQL is a strongly typed language where the structure of the query output is determined without any consideration of whether said

Re: Outer joins and NULLs (old subject "ERROR: failed to find conversion function from key_vals_nn to record[]")

Bryn Llewellyn writes: > Self-evidently, a view does *not* inherit constraints from the columns of its > base table(s). Check. > A view on a single table doesn't necessarily inherit the data types of its > base table's columns. Rather, the view compilation's analysis is *sometimes* > clever

Re: '{"x": 42, "y": null}'::jsonb != '{"x": 42}'::jsonb ... Really?

Bryn Llewellyn schrieb am 04.06.2022 um 03:41: Am I missing a use case where an object with a key-value pair with a JSON null value is meaningfully different from one where the key is simply absent? It seems the JSON specification doesn't actually define equality. But the JSON patch RFC 6902[1]

Re: '{"x": 42, "y": null}'::jsonb != '{"x": 42}'::jsonb ... Really?

> jian.universal...@gmail.com wrote: > >> b...@yugabyte.com wrote: >> >> /* — START OF SPEC —— */ >> >> The document's top-level object may use only these keys: >> >> ... >> >> And the meaning of *not required* is simply "no information is available for >>

Outer joins and NULLs (old subject "ERROR: failed to find conversion function from key_vals_nn to record[]")

> b...@yugabyte.com wrote: > >> david.g.johns...@gmail.com wrote: >> >>> b...@yugabyte.com wrote: >>> >>> Can anybody show me an implementation of a realistic use case that follows >>> proper practice — like "every table must a

Re: Index creation

On Sun, Jun 19, 2022 at 12:06 PM Дмитрий Иванов wrote: > Good afternoon. > I have a query parser question. If there are two kinds of queries using an > indexed field. In this case, one view is limited to this field, the second > one uses a number of fields included in the index by the include

Index creation

Good afternoon. I have a query parser question. If there are two kinds of queries using an indexed field. In this case, one view is limited to this field, the second one uses a number of fields included in the index by the include directive. It makes sense to have two indexes, lightweight and

Re: '{"x": 42, "y": null}'::jsonb != '{"x": 42}'::jsonb ... Really?

On Sat, Jun 18, 2022 at 5:44 AM Bryn Llewellyn wrote: > > */* — START OF SPEC —— */* > > > *The document's top-level object may use only these keys:* > > *"isbn" — string* > *values must be unique across the entire set of documents (in other words, > it defines