On Thu, Jul 14, 2022 at 6:08 PM Bruce Momjian wrote:
> On Wed, Feb 9, 2022 at 01:02:51PM +, PG Doc comments form wrote:
> > The following documentation comment has been logged on the website:
> >
> > Page: https://www.postgresql.org/docs/14/sql-createtableas.html
> > Description:
> >
> > If
On Wed, Feb 9, 2022 at 01:02:51PM +, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/14/sql-createtableas.html
> Description:
>
> If I create a table with CREATE TABLE IF NOT EXISTS table_name AS, and
On Wed, Mar 16, 2022 at 09:28:04AM +0100, Laurenz Albe wrote:
> On Tue, 2022-03-15 at 16:12 +, PG Doc comments form wrote:
> > Page: https://www.postgresql.org/docs/14/backup-dump.html
> >
> > As far as I can see, the terms "Reload" and "Restore" are used
> > interchangeably.
> > To make the p
On Tue, May 24, 2022 at 08:36:18AM -0400, Bruce Momjian wrote:
> fOn Sat, May 14, 2022 at 05:21:58PM +0200, Álvaro Herrera wrote:
> > On 2022-May-13, Bruce Momjian wrote:
> > > Note that valid --auth option values are all lower case, even
> > > for authentication types that typically appear as
On Sat, Jul 9, 2022 at 10:38:30PM -0400, Bruce Momjian wrote:
> > (source: https://www.postgresql.org/docs/devel/pgupgrade.html)
> >
> > I'm a new contributor so please forgive me if I'm on the wrong track,
> > but if you follow this step, won't you also be ensuring that replication
>
On Thu, Jul 14, 2022 at 02:41:45AM +, ideriha.take...@fujitsu.com wrote:
> Bruce Momjian wrote:
>
> > This is a very good point. I have studied the issue and created the
> > attached patch to document Oracle-compatibility mode.
>
> Hi Bruce, thank you for writing the document.
> I checked
On Mon, Jul 11, 2022 at 06:50:30PM -0500, Troy Frericks wrote:
>
> Looks awesome!
Patch applied to all supported versions --- thanks for your report.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Indecision is a decision.
>> No, there is no guarantee. It's just that UNION ALL works this way today
>> (preserving the order of the subselects) - and I'm not even sure about
>> that, it may not preserve the order in all cases, with different indexes
or
>> partitioning or a parallel plan, etc.
>
> Yeah, that. You can get
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/12/functions-admin.html
Description:
Hello!
There is no information in documentation about pg_advisory_unlock with NULL
value.
This call: select pg_advisory_unlock(null), returns null without
On Thursday, July 14, 2022, Shay Rojansky wrote:
>
> If there's a guarantee that UNION ALL preserves ordering - as Tom seems to
> indicate in the thread quoted above - then the above works. If there's no
> such guarantee, then AFAIK the above can't be rewritten; putting the ORDER
> BY outside - o
Pantelis Theodosiou writes:
> On Thu, Jul 14, 2022 at 9:16 AM Shay Rojansky wrote:
>> I was trying to understand what - if any - are the guarantees with
>> regards to ordering for combining queries (UNION/UNION ALL/...).
> No, there is no guarantee. It's just that UNION ALL works this way today
On Thu, Jul 14, 2022 at 9:16 AM Shay Rojansky wrote:
>
> >> I was trying to understand what - if any - are the guarantees with
> regards to ordering for combining queries (UNION/UNION ALL/...). From this
> message[1], it seems that UNION ALL does preserve the ordering of the
> operand queries, wh
>> I was trying to understand what - if any - are the guarantees with
regards to ordering for combining queries (UNION/UNION ALL/...). From this
message[1], it seems that UNION ALL does preserve the ordering of the
operand queries, whereas UNION does not (presumably neither do INTERSECT,
INTERSECT
13 matches
Mail list logo
