-hackers,
The community has spent a lot of time optimizing features over the years.
Excellent examples include parallel query and partitioning which have been
multi-year efforts to increase the quality, performance, and extend
features of the original commit. We should consider the documentation
>
>
>>
>> Technical documentation should only be as verbose as needed to illustrate
>> the concept or task that we are explaining. It should not be redundant, nor
>> should it use .50 cent words when a .10 cent word would suffice. I would
>> like to put effort into optimizing the documentation and
>
>
>
> > This is the official PostgreSQL documentation. It is written by the
> > PostgreSQL community in parallel with the development of the software.
> > We have organized it by the type of user and their stages of experience:
>
> Some thoughts on this example:
>
> - Changing "has been" to "is"
>
>
>
> In short, the devil's in the details. Maybe there are lots of
> places where this type of approach would help, but I think it's
> going to be a case-by-case discussion not something where there's
> a clear win overall.
>
Certainly and I didn't want to just start dumping patches. Part of t
>
>
>
> > Queries can also access multiple tables at once, or access the same table
> > in a way that multiple rows are processed. A query that accesses multiple
> > rows of the same or different tables at one time is a join. For example,
> if
> > you wish to list all of the weather records with th
On Wed, Dec 30, 2020 at 3:47 PM Bruce Momjian wrote:
>
> I will say that if the community feels external-only should be the only
> option, I will stop working on this feature because I feel the result
> would be too fragile to be reliable, and I would not want to be
> associated with it.
>
>
I ca
>
>
> > >I will say that if the community feels external-only should be the only
> > >option, I will stop working on this feature because I feel the result
> > >would be too fragile to be reliable,
> >
> > I'm do not see why it would be the case. I'm just arguing to have key
> > management in a sep
>
>
>
> Also, I'm not sure that many extensions would really benefit from custom
> utility command, as you can already do pretty much anything you want using
> SQL
> functions. For instance it would be nice for hypopg to be able to support
>
> CREATE HYPOTHETICAL INDEX ...
>
> rather than
>
> SELE
Howdy,
Well I certainly wasn't trying to make work out of that blog but I am glad
to see it was productive.
JD
On Thu, Nov 19, 2020 at 2:43 PM Tom Lane wrote:
> After digging a bit more I noticed that we'd discussed removing
> IS OF in the 2007 thread, but forebore because there wasn't an easy
On Wed, Feb 10, 2021 at 11:04 AM Tom Lane wrote:
> "Jonah H. Harris" writes:
> > On Wed, Feb 10, 2021 at 1:10 PM Tom Lane wrote:
> >> ... If we start having
> >> modes for MySQL identifier quoting, Oracle outer join syntax, yadda
> >> yadda, it's going to be way more of a maintenance nightmare
On Thu, Jul 28, 2022 at 9:52 AM Robert Haas wrote:
> On Thu, Jul 28, 2022 at 11:59 AM Alvaro Herrera
> wrote:
> > I do wonder why do we keep relfilenodes limited to decimal digits. Why
> > not use hex digits? Then we know the limit is 14 chars, as in
> > 0x00FF in the MAX_RELFILENU
-Hackers,
I came across this today [1], "
3 Results
In most respects, PostgreSQL behaved as expected: both read uncommitted and
read committed prevent write skew and aborted reads. We observed no
internal consistency violations. However, we have two surprising results to
report. The first is that
>
>
> From: Jose Luis Tallon
>
> > Musing some other date-related things I stumbled upon the thought
> > that naming the upcoming release PostgreSQL 20 might be preferrable to
> > the current/expected "PostgreSQL 13".
>
> +1
>
> Users can easily know how old/new the release is that they are u
13 matches
Mail list logo
