On Mon, Aug 03, 2020 at 07:23:48AM -0400, Tom Lane wrote:
> So I don't think it's a clerical error, but certainly showing these
> operators this way is none too helpful. Perhaps including the input types
> in this table (and its siblings elsewhere) would be a good thing.
Ah, thanks. I did not co
On Tue, Aug 4, 2020 at 10:24 AM Bruce Momjian wrote:
> On Mon, Aug 3, 2020 at 01:41:24AM +, PG Doc comments form wrote:
> > The following documentation comment has been logged on the website:
> >
> > Page: https://www.postgresql.org/docs/12/mvcc-intro.html
> > Description:
> >
> > The documen
On Mon, Aug 3, 2020 at 01:41:24AM +, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/12/mvcc-intro.html
> Description:
>
> The documentation page:
> __https://www.postgresql.org/docs/12/mvcc-intro.htm
On Mon, Aug 3, 2020 at 05:39:47PM -0400, Alvaro Herrera wrote:
> On 2020-Aug-03, Bruce Momjian wrote:
>
> > So, the character and octet length is 600 million, but on output, that
> > will be expanded, and both SELECT and pg_dump fail. I also can't see
> > how to improve the error message since i
On 2020-Aug-03, Bruce Momjian wrote:
> So, the character and octet length is 600 million, but on output, that
> will be expanded, and both SELECT and pg_dump fail. I also can't see
> how to improve the error message since it happens so low in the stack.
I think you'll find commits fa2fa9955280 a
On Thu, Jul 30, 2020 at 10:31:49PM +, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/12/datatype-numeric.html
> Description:
>
> When I try to run
> `insert into employees (r_id) values (3.919192199
On Mon, Aug 3, 2020 at 04:44:38PM -0400, Joe Conway wrote:
> It is easier to reproduce than that:
>
> select repeat('x',6)::bytea;
> ERROR: invalid memory alloc request size 120003
>
> select octet_length(repeat('x',6)::bytea);
> octet_length
> --
> 6000
On 8/3/20 4:20 PM, Bruce Momjian wrote:
> On Fri, Jul 31, 2020 at 10:13:48AM +0500, Andrey M. Borodin wrote:
>> Hi Anna!
>>
>> > 23 мая 2018 г., в 20:33, Anna Akenteva
>> > написал(а):
>> >
>> >
>> > Some time ago I've encountered a problem with the bytea type: we can't
>> > SELECT
>> > bytea
On Fri, Jul 31, 2020 at 10:13:48AM +0500, Andrey M. Borodin wrote:
> Hi Anna!
>
> > 23 мая 2018 г., в 20:33, Anna Akenteva
> > написал(а):
> >
> >
> > Some time ago I've encountered a problem with the bytea type: we can't
> > SELECT
> > bytea strings whose textual representation is too big to
Michael Paquier writes:
> On Mon, Aug 03, 2020 at 03:14:56PM +0800, osdba wrote:
>> "range_opsany range type&& &> &< >> << <@ -|- = @> @>"， exist double "@>"，
>> Should be "<@ @>" ?
> Indeed, this needs to be improved. Another issue on the same page is
> that point_ops lists the same operator th
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/12/mvcc-intro.html
Description:
The documentation page:
__https://www.postgresql.org/docs/12/mvcc-intro.html
makes a reference to the term "innovative Serializable Snapshot Isolation
(SSI) le
On Mon, Aug 03, 2020 at 03:14:56PM +0800, osdba wrote:
> "range_opsany range type&& &> &< >> << <@ -|- = @> @>"， exist double "@>"，
>
> Should be "<@ @>" ?
Indeed, this needs to be improved. Another issue on the same page is
that point_ops lists the same operator three times, <@. Other index
p
hi all:
In Document "Table 59-1. Built-in GiST Operator Classes":
"range_opsany range type&& &> &< >> << <@ -|- = @> @>"， exist double "@>"，
Should be "<@ @>" ?
13 matches
Mail list logo
