demirgok...@gmail.com writes:
> The following documentation comment has been logged on the website:
> Page: https://www.postgresql.org/docs/9.4/static/datatype-json.html
> Description:
> Shouldn't be below statement:
> "Although the jsonb_path_ops operator class supports only queries with
> the
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/9.4/static/datatype-json.html
Description:
Shouldn't be below statement:
"Although the jsonb_path_ops operator class supports only queries with the
@> operator, it has notable performance a
2017-10-09 6:07 GMT-03:00 :
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/9.4/static/explicit-locking.html
> Description:
>
> The documentation says :
>
> "This lock mode is not automatically acquired by any PostgreSQL
> command."
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/9.4/static/explicit-locking.html
Description:
The documentation says :
"This lock mode is not automatically acquired by any PostgreSQL
command."
I am wrong if I say that a "ADD CONSTRAINT
In my previous email I quoted an incorrect hashing speed.
The correct speed should be 200GH/sec, and thus, 11 seconds to
bruteforce all 8 character combinations of a-zA-Z0-9 - using the
calculator at http://calc.opensecurityresearch.com/
Apologies for any confusion.
--
Sent via pgsql-docs mail
2013/7/31 Fujii Masao :
> On Wed, Jul 31, 2013 at 1:49 PM, Ian Lawrence Barwick
> wrote:
>> Hi
>>
>> The last paragraph on the page "21.6. Tablespaces":
>>
>> "and after you restart the server, update the pg_tablespace catalog
>> with the new locations"
>>
>> is partially inaccurate as of Postgr
On Wed, Jul 31, 2013 at 1:49 PM, Ian Lawrence Barwick wrote:
> Hi
>
> The last paragraph on the page "21.6. Tablespaces":
>
> "and after you restart the server, update the pg_tablespace catalog
> with the new locations"
>
> is partially inaccurate as of PostgreSQL 9.2, as the spclocation
> column
Hi
The last paragraph on the page "21.6. Tablespaces":
"and after you restart the server, update the pg_tablespace catalog
with the new locations"
is partially inaccurate as of PostgreSQL 9.2, as the spclocation
column which is meant
here was removed in 9.2 [2]).
Patch attached; I also added a
On Thu, 2010-09-02 at 15:24 -0700, Josh Berkus wrote:
> >> This paragraph leaves a *lot* to be desired from an accuracy perspective
> >
> > Really? Exactly which statements will you claim are incorrect?
>
> That the int type is definitely faster on all platforms regardless of
> circumstances. E
> To this:
>
> On 32-bit operating systems, or when PostgreSQL is complied 32-bit,
On 32-bit architectures, or when PostgreSQL is compiled as 32-bit
binaries, operations using bigint may be slower than those with
---
The problem I have with words like significant is that bigint is not
noticeabl
>> This paragraph leaves a *lot* to be desired from an accuracy perspective
>
> Really? Exactly which statements will you claim are incorrect?
That the int type is definitely faster on all platforms regardless of
circumstances. Especially the circumstance where the user really needs
a bigint a
Josh Berkus writes:
> "The type integer is the common choice, as it offers the best balance
> between range, storage size, and performance. The smallint type is
> generally only used if disk space is at a premium. The bigint type
> should only be used if the integer range is insufficient, because
All,
This is currently in:
http://www.postgresql.org/docs/current/interactive/datatype-numeric.html#DATATYPE-INT
"The type integer is the common choice, as it offers the best balance
between range, storage size, and performance. The smallint type is
generally only used if disk space is at a prem
At least two other popular production database products provide true
serializability, as described in PostgreSQL documentation (section 12.2.2.1 of
8.1 devel). I'm a big fan of PosgreSQL, but let's not overstate things. Some
users may have applications with do depend on the true serializabilit
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> You are confusing SQL and PL/pgSQL.
>
> > Any idea why they don't match between SQL and PL/pgSQL.
>
> Different lexers.
>
> We could talk about extending plpgsql's lexer to handle comments the
> same way as the
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> You are confusing SQL and PL/pgSQL.
> Any idea why they don't match between SQL and PL/pgSQL.
Different lexers.
We could talk about extending plpgsql's lexer to handle comments the
same way as the main SQL lexer, but it doesn't do so
Tom Lane wrote:
> John DeSoi <[EMAIL PROTECTED]> writes:
> > From the example below and looking at scan.c, it seems that nested
> > block comments are supported.
>
> You are confusing SQL and PL/pgSQL.
Any idea why they don't match between SQL and PL/pgSQL.
--
Bruce Momjian
John DeSoi <[EMAIL PROTECTED]> writes:
> From the example below and looking at scan.c, it seems that nested
> block comments are supported.
You are confusing SQL and PL/pgSQL.
regards, tom lane
---(end of broadcast)---
TIP
From the example below and looking at scan.c, it seems that nested
block comments are supported.
test=# select /* /* nested */ */ 1;
?column?
--
1
(1 row)
From section 35.3:
There are two types of comments in PL/pgSQL. A double dash (--) starts
a comment that extends to the en
19 matches
Mail list logo
