>> 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
>> 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
Greetings.
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,
I
On Sun, Jun 5, 2022 at 10:27 AM Julien Rouhaud wrote:
> As mentioned in the doc in [3], COALESCE and all the others are actually
not
functions (those are specific keywords handled in the parser):
Thanks. Yeah, I noticed that comment, but NULLIF which is also documented
on that page isn't mention
Hi all,
The PostgreSQL docs mostly show function names in lowercase (e.g. [1],
[2]), which seems to be the PostgreSQL-idiomatic thing to do. However, some
pages show functions in upper case, e.g. COALESCE/NULLIF/GREATEST/LEAST
([3]). Is there some difference between these which warrants the case
d
Hi all,
range_intersect_agg is documented to return anymultirange (on this
page[1]), but it actually returns a range.
In addition, range_intersect_agg also accepts a multirange as its
parameter, but that's not documented on the same page. Note that range_agg
does *not* accept a multirange (possib
> > Second, across the protocol docs, rather than using Int32 and Int64,
> which
> > generally look like they're signed (depending on which language you're
> > coming from), I'd consider using UInt32/UInt64, which are unambiguous
> with
> > regards to signed-ness.
>
> Well, they are actually signed
Thanks for your attention to this.
I'm definitely not a cryptography expert, but it seems to me that the
actual mechanisms (MD5, SHA-256) are more important than the protocols used
to negotiate them (SASL, SCRAM). When some security expert unfamiliar with
PostgreSQL goes over itss documentation to
