ings worse in this respect. Do you think we should address this
> too? I suspect that describing the difference between the header and
> the type tag here will create even more confusion.
I said nothing about describing the difference between the header and
type tag. The patch added xxx's for the type tag in a comment about
the header. This is more misleading than what is there now.
--
John Naylor
EDB: http://www.enterprisedb.com
On Mon, Sep 5, 2022 at 1:18 AM Andres Freund wrote:
>
> Hi,
>
> On 2022-09-04 12:16:10 +0700, John Naylor wrote:
> > Pushed 01 and 02 separately, then squashed and pushed the rest.
>
> Thanks a lot! It does look a good bit cleaner to me now.
>
> I think, as a follow
On Mon, Sep 5, 2022 at 4:11 AM Andres Freund wrote:
>
> Hi,
>
> On 2022-09-04 13:12:52 +0700, John Naylor wrote:
> > On Fri, Sep 2, 2022 at 11:35 PM Andres Freund wrote:
> > >
> > > Hi,
> > >
> > > On 2022-09-02 14:17:26 +0700, John Naylo
Here are autoconf-only patches to that effect.
--
John Naylor
EDB: http://www.enterprisedb.com
From 5e07442ebf728c486536038aecf29aefcc892455 Mon Sep 17 00:00:00 2001
From: John Naylor
Date: Tue, 6 Sep 2022 11:41:58 +0700
Subject: [PATCH v2 2/2] Bump minimum version of Flex to 2.5.35
Since the retirement o
arning".
>
> A positive argument for doing nothing is that there's room to worry
> whether -D__STDC_WANT_LIB_EXT1__ might have any side-effects we
> *don't* want.
This is still listed in the CF as needing review, so I went and marked
it rejected.
--
John Naylor
EDB: http://www.enterprisedb.com
On Fri, Sep 2, 2022 at 11:35 PM Andres Freund wrote:
>
> Hi,
>
> On 2022-09-02 14:17:26 +0700, John Naylor wrote:
> > On Thu, Sep 1, 2022 at 1:12 AM Andres Freund wrote:
> > > [v12]
> >
> > +# Build a small utility static lib for the parser. This ma
o how I
did json path in the last patch. Also removed the bogus include from
v4 to . Pushed 01 and 02 separately, then squashed and pushed the
rest.
--
John Naylor
EDB: http://www.enterprisedb.com
On Sat, Sep 3, 2022 at 12:57 PM Tom Lane wrote:
>
> John Naylor writes:
> > On Sat, Sep 3, 2022 at 12:30 PM Pavel Stehule
> > wrote:
> >> /usr/local/pgsql/master/include/server/port/simd.h: In function
> >> ‘vector8_has’:
> >> /usr/local/pgsql/mast
r (int i = 0; i < sizeof(Vector8); i++)
> | ^
"int" should probably be "Size" -- does that remove the warning?
--
John Naylor
EDB: http://www.enterprisedb.com
header
> > Subject: [PATCH v4 03/11] Build guc-file.c standalone
>
> 01-03 are a bit more complicated, but still look not far off. There's a FIXME
> about failing headercheck.
--
John Naylor
EDB: http://www.enterprisedb.com
ome buildfarm animals recently, it seems the
oldest perl there is 5.14? ... which came out in 2011, so it seems
later on we could just set that as the minimum.
--
John Naylor
EDB: http://www.enterprisedb.com
On Fri, Sep 2, 2022 at 12:17 PM Kyotaro Horiguchi
wrote:
>
> At Thu, 01 Sep 2022 18:22:06 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > At Thu, 1 Sep 2022 15:00:38 +0700, John Naylor
> > wrote in
> > > UnicodeData.txt has this:
> > >
> > > 200
On Wed, Aug 31, 2022 at 11:17 AM Nathan Bossart
wrote:
>
> On Wed, Aug 31, 2022 at 10:50:39AM +0700, John Naylor wrote:
> > Here's the final piece. I debated how many tests to add and decided it
> > was probably enough to add one each for checking quotes and
> > back
GHT-TO-LEFT MARK;Cf;0;R;N;
So maybe we need to take Cf characters in this file into account, in
addition to Me and Mn (combining characters).
--
John Naylor
EDB: http://www.enterprisedb.com
On Tue, Aug 23, 2022 at 1:03 PM John Naylor
wrote:
>
> LGTM overall. My plan is to split out the json piece, adding tests for
> that, and commit the infrastructure for it fairly soon.
Here's the final piece. I debated how many tests to add and decided it
was probably enough to add
On Tue, Aug 30, 2022 at 12:17 AM Nathan Bossart
wrote:
> Thanks! I've attached a follow-up patch with a couple of small
> suggestions.
Pushed, thanks!
--
John Naylor
EDB: http://www.enterprisedb.com
On Mon, Aug 29, 2022 at 4:28 PM John Naylor
wrote:
>
> Here's the simplest fix I can think of:
>
> /*
> * Exactly like vector8_is_highbit_set except for the input type, so
> it still looks
> * at each _byte_ separately.
> *
> * XXX x86 uses the same underlying
On Mon, Aug 29, 2022 at 3:19 PM John Naylor
wrote:
>
> It turns out MSVC animal drongo doesn't like this cast -- on x86 they
> are the same underlying type. Will look into that as more results come
> in.
Here's the simplest fix I can think of:
/*
* Exactly like vector8_is_highbi
On Mon, Aug 29, 2022 at 11:25 AM John Naylor
wrote:
> +static inline bool
> +vector32_is_highbit_set(const Vector32 v)
> +{
> +#ifdef USE_SSE2
> + return (_mm_movemask_epi8(v) & 0x) != 0;
> +#endif
> +}
>
> I'm not sure why we need this function -- AFAICS
On Mon, Aug 29, 2022 at 12:44 PM Nathan Bossart
wrote:
> [v6]
Pushed with a couple comment adjustments, let's see what the build
farm thinks...
--
John Naylor
EDB: http://www.enterprisedb.com
meliorated. As I said in the dual pivot
thread, this would be great for dual pivot since we could reuse
partial insertion sort for choosing the pivots, reducing binary space.
--
John Naylor
EDB: http://www.enterprisedb.com
wonder if we should explain briefly what saturating arithmetic is. I
had never encountered it outside of a SIMD programming context.
--
John Naylor
EDB: http://www.enterprisedb.com
On Sat, Aug 27, 2022 at 2:23 PM Andres Freund wrote:
>
> Hi,
>
> On 2022-08-27 12:53:24 +0700, John Naylor wrote:
> > Update: I tried taking the CI for a spin, but ran into IT issues with
> > Github when I tried to push my branch to remote.
>
> A github, not a CI is
cast(c));
+ result = vector8_has_zero(sub);
I think we should invent a helper that does saturating subtraction and
call that, inlining the sub var so we don't need to mess with it
further.
Otherwise seems fine.
--
John Naylor
EDB: http://www.enterprisedb.com
On Sat, Aug 27, 2022 at 11:20 AM John Naylor
wrote:
>
> Here's a patch with that idea, not tested on Windows yet.
Update: I tried taking the CI for a spin, but ran into IT issues with
Github when I tried to push my branch to remote.
--
John Naylor
EDB: http://www.enterprisedb.com
On Sat, Aug 27, 2022 at 10:02 AM Tom Lane wrote:
>
> John Naylor writes:
> > On Sat, Aug 27, 2022 at 4:15 AM Andres Freund wrote:
> >> I think it'd also be needed in hstore_plperl.c, jsonb_plperl.c. Putting the
> >> include in plperl.h would keep th
Putting the
> include in plperl.h would keep that aspect transparent, because plperl_utils.h
> includes plperl.h.
Since plperl_helpers.h already includes plperl.h, I'm not sure why
both are included everywhere the former is. If .c/.xs files didn't
include plperl.h directly, we could keep pg_wchar.h in
plperl_helpers.h. Not sure if that's workable or any better...
--
John Naylor
EDB: http://www.enterprisedb.com
> mb/pg_wchar.h include out to before we include all the perl stuff. That does
> fix the issue.
We could also move is_valid_ascii somewhere else. It's only
tangentially related to "wide chars" anyway.
--
John Naylor
EDB: http://www.enterprisedb.com
and without
the patch, to see how the inflection point shifts. That worked pretty
well when testing dual-pivot.
--
John Naylor
EDB: http://www.enterprisedb.com
From fd4bfdbee88478fac32838712c112d91f73c5db5 Mon Sep 17 00:00:00 2001
From: John Naylor
Date: Wed, 4 May 2022 23:35:06 +0700
Subject: [PATCH
On Fri, Aug 26, 2022 at 10:26 AM Nathan Bossart
wrote:
>
> On Thu, Aug 25, 2022 at 04:41:53PM +0700, John Naylor wrote:
> > v3 applies on top of the v9 json_lex_string patch in [1] and adds a
> > bit more to that, resulting in a simpler patch that is more amenable
> > to
On Thu, Aug 25, 2022 at 1:35 PM John Naylor
wrote:
>
> I think I'll go ahead and commit 0001 in a couple days pending further
> comments.
Pushed with Nathan's correction and some cosmetic rearrangements.
--
John Naylor
EDB: http://www.enterprisedb.com
"==" instead of "<=" for this one?
Good catch, will fix.
--
John Naylor
EDB: http://www.enterprisedb.com
On Thu, Aug 25, 2022 at 11:57 AM Nathan Bossart
wrote:
>
> On Thu, Aug 25, 2022 at 10:38:34AM +0700, John Naylor wrote:
> > On Thu, Aug 25, 2022 at 1:01 AM Nathan Bossart
> > wrote:
> >> On Wed, Aug 24, 2022 at 11:07:03AM +0700, John Naylor wrote:
> >> > -
--
John Naylor
EDB: http://www.enterprisedb.com
diff --git a/src/common/wchar.c b/src/common/wchar.c
index 1e6e198bf2..1ca7533f00 100644
--- a/src/common/wchar.c
+++ b/src/common/wchar.c
@@ -1918,11 +1918,12 @@ pg_utf8_verifystr(const unsigned char *s, int len)
const int orig_len = len;
uint32 state
On Wed, Aug 24, 2022 at 11:56 PM Nathan Bossart
wrote:
>
> On Wed, Aug 24, 2022 at 11:59:25AM +0700, John Naylor wrote:
> > It seems "scalar" would be a bad choice since it already means
> > (confusingly) operating on the least significant element of a vecto
On Thu, Aug 25, 2022 at 1:01 AM Nathan Bossart wrote:
>
> On Wed, Aug 24, 2022 at 11:07:03AM +0700, John Naylor wrote:
> > The important thing is: if we compile with __aarch64__ as a target:
> > - Will the compiler emit the intended instructions from the intrinsics
> > wit
On Wed, Aug 24, 2022 at 12:15 AM Nathan Bossart
wrote:
>
> On Tue, Aug 23, 2022 at 01:03:03PM +0700, John Naylor wrote:
> > On Tue, Aug 23, 2022 at 10:32 AM Nathan Bossart
> >> Here's a new version of the patch with the 32-bit changes and calls to
> >> lfind() rem
On Tue, Aug 23, 2022 at 4:15 AM Nathan Bossart wrote:
>
> On Mon, Aug 22, 2022 at 11:50:35AM +0700, John Naylor wrote:
> > Is this also ever defined on 32-bit? If so, is it safe, meaning the
> > compiler will not emit these instructions without additional flags?
> > I'm w
On Tue, Aug 23, 2022 at 11:24 AM David Rowley wrote:
>
> On Tue, 23 Aug 2022 at 15:22, John Naylor
> wrote:
> > Did you happen to see
> >
> > https://www.postgresql.org/message-id/CAFBsxsFhq8VUSkUL5YO17cFXbCPwtbbxBu%2Bd9MFrrsssfDXm3Q%40mail.gmail.com
>
> I m
On Tue, Aug 23, 2022 at 10:32 AM Nathan Bossart
wrote:
>
> On Mon, Aug 22, 2022 at 02:22:29PM -0700, Nathan Bossart wrote:
> > On Mon, Aug 22, 2022 at 09:35:34AM +0700, John Naylor wrote:
> >> Not at all! However, the 32-bit-element changes are irrelevant for
> >&
, and (only if there
are additional sort keys) once on the null partition. And the
pre-partitioning would take care of nulls first/last upfront. I
haven't looked into the feasibility of this yet, but the good thing
about the concept is that it removes null handling in the comparators
without addition
On Tue, Aug 23, 2022 at 7:14 AM Peter Smith wrote:
>
> I noticed an accidental ;;
>
> PSA patch to remove the same.
Pushed.
--
John Naylor
EDB: http://www.enterprisedb.com
onal flags?
I'm wondering if __aarch64__ would be clearer on that, and if we get
windows-on-arm support as has been proposed, could also add _M_ARM64.
I also see #if defined(__aarch64__) || defined(__aarch64) in our
codebase already, but I'm not sure what recognizes the latter.
--
John Naylor
EDB: http://www.enterprisedb.com
it has a different API,
requires new functions we don't need, and possibly has portability
issues. A simple for-loop is better for assertions.
- A runtime elog is not appropriate for a compile time check -- use
#error instead.
--
John Naylor
EDB: http://www.enterprisedb.com
On Tue, Aug 16, 2022 at 4:23 AM Nathan Bossart wrote:
>
> On Mon, Aug 15, 2022 at 08:33:21PM +0700, John Naylor wrote:
> > +#ifdef USE_SSE2
> > + chunk = _mm_loadu_si128((const __m128i *) [i]);
> > +#else
> > + memcpy(, [i
ude "postgres.h"
#include "cubedata.h"
+#include "cube_internal.h"
#include "utils/float.h"
--
John Naylor
EDB: http://www.enterprisedb.com
ed to be defined in a semi-public header? If we do this
> > > > in
> > > > multiple files we'll end up with the danger of macro redefinition
> > > > warnings.
>
> For v4, I #defined YYSTYPE
Sorry for the misfire. Continuing on, I #defined YYSTYPE in cubesca
On Wed, Aug 17, 2022 at 8:14 AM Andres Freund wrote:
>
> Hi,
>
> On 2022-08-16 17:41:43 +0700, John Naylor wrote:
> > For v3, I addressed some comments and added .h files to the
> > headerscheck exceptions.
>
> Thanks!
>
>
> > /*
> > * NB: incl
AG_EXPANDED_RO = 2,
VARTAG_EXPANDED_RW = 3,
VARTAG_ONDISK = 18
} vartag_external;
And I don't think the new comments referring to "third case", "first
two cases", etc make it easier to follow.
--
John Naylor
EDB: http://www.enterprisedb.com
On Tue, Aug 16, 2022 at 8:48 AM John Naylor
wrote:
>
> On Fri, Aug 12, 2022 at 8:55 PM Tom Lane wrote:
> >
> > John Naylor writes:
> > > This is really a straw-man proposal, since I'm not volunteering to do
> > > the work, or suggest anybody else should do
included to e.g. define a PL transform or a new operator or
> ... This would be solved by the %code requires thing, right?
I believe it would.
--
John Naylor
EDB: http://www.enterprisedb.com
For v3, I addressed some comments and added .h files to the
headerscheck exceptions.
On Tue, Aug 16, 2022 at 1:11 AM Andres Freund wrote:
> On 2022-08-13 15:39:06 +0700, John Naylor wrote:
> > Here are the rest. Most of it was pretty straightforward, with the
> >
On Fri, Aug 12, 2022 at 8:55 PM Tom Lane wrote:
>
> John Naylor writes:
> > This is really a straw-man proposal, since I'm not volunteering to do
> > the work, or suggest anybody else should do the same. That being the
> > case, it seems we should just go a
On Mon, Aug 15, 2022 at 12:39 PM Masahiko Sawada wrote:
>
> On Fri, Jul 22, 2022 at 10:43 AM Masahiko Sawada
> wrote:
> >
> > On Tue, Jul 19, 2022 at 1:30 PM John Naylor
> > wrote:
> > >
> > >
> > >
> > > On Tue, Jul 19, 2022 a
ext AS
with long as (
select repeat(description, 11)
from pg_description
)
select (select json_agg(row_to_json(long))::text as t from long) from
generate_series(1, 100);
VACUUM FREEZE long_json_as_text;
select 1 from long_json_as_text where t::json is null; -- from Andrew upthread
ill welcome
comments on that.
--
John Naylor
EDB: http://www.enterprisedb.com
From da2b610b8608e6759f5ed9cc32b487ea8e750ce4 Mon Sep 17 00:00:00 2001
From: John Naylor
Date: Fri, 12 Aug 2022 17:09:45 +0700
Subject: [PATCH v201 3/9] Build repl_scanner.c standalone
---
src/backend/replication/Makefile |
in the attached. I took a quick look to see if that
would enable anything useful, but nothing stuck out.
Aside: The MSVC builds don't report the Bison version that I can see,
but otherwise it seems now the only non-Apple pre-3.0 animals are
prion (2.7) and the three Sparc animals on Debian 7 (2.5).
I wrote:
> On Thu, Aug 4, 2022 at 8:41 PM Tom Lane wrote:
> >
> > John Naylor writes:
>
> > > RepOriginId is a typedef for uint16, so this can't print the wrong answer,
> > > but it is inconsistent with other uses. So it seems we don't need to
> > &g
ld/intractable cruft from the TODO list, but we should also be
sticking small nice-but-not-necessary things in there. That said, if
this idea has any bearing on the guc_internal.h idea, it might be
better dealt with now.
--
John Naylor
EDB: http://www.enterprisedb.com
From d723ba14acf56fd432e9e263db937
ormance.
Creating a zeroed register is just FOO PXOR FOO, which should get
hoisted out of the (unrolled in this case) loop, and which a recent
CPU will just map to a hard-coded zero in the register file, in which
case the execution latency is 0 cycles. :-)
--
John Naylor
EDB: http://www.enterprisedb.com
On Thu, Aug 11, 2022 at 10:37 AM Tom Lane wrote:
>
> John Naylor writes:
> > With a bit of work, we could probably get rid of those includes. See
> > 27199058d98ef7f for one example.
>
> Yeah --- it would mean creating gram.h files for all the bison grammars
> not j
.c
With a bit of work, we could probably get rid of those includes. See
27199058d98ef7f for one example.
--
John Naylor
EDB: http://www.enterprisedb.com
On Thu, Aug 11, 2022 at 4:46 AM Nathan Bossart wrote:
>
> On Wed, Aug 10, 2022 at 10:50:02AM +0700, John Naylor wrote:
> > LGTM, let's see what the buildfarm thinks of 0001.
>
> Thanks! I haven't noticed any related buildfarm failures yet.
I was waiting for all the Windows
o varlen fields. I imagine keeping track of the attributes
length will come up for some types and might be tricky. And before
that, the catalog machinery will need some preprocessor tricks to
declare pointers in the structs.
--
John Naylor
EDB: http://www.enterprisedb.com
From 20fba44412e8ef1bb4cd5b051b
of code and it's difficult to see what's different for
each platform, IMO.
--
John Naylor
EDB: http://www.enterprisedb.com
From 69d56a21192ed2f03bc08f078cfff7ba5cb0d80b Mon Sep 17 00:00:00 2001
From: John Naylor
Date: Fri, 5 Aug 2022 13:30:47 +0700
Subject: [PATCH v2] Use SSE2 in is_valid_ascii wher
(). Here
> is an example.
LGTM, let's see what the buildfarm thinks of 0001.
--
John Naylor
EDB: http://www.enterprisedb.com
rst for that reason.
It's simpler than the qsort/qunique/binary search that was there
before, so that's nice, but I've not tried to test performance.
--
John Naylor
EDB: http://www.enterprisedb.com
From 1c89b9b7d3c71bb1a703caaf7c01c93bc9e2515f Mon Sep 17 00:00:00 2001
From: John Naylor
Date: Tue
On Tue, Aug 9, 2022 at 8:58 AM Masahiko Sawada wrote:
> I found that there are two .c and .h files whose identification in the
> header comment doesn't match its actual path.
> The attached small patch fixes them.
Pushed, thanks!
--
John Naylor
EDB: http://www.enterprisedb.com
, as far as I'm concerned. I'm interested in using a char
version for json strings.
> 3) Can pg_lfind32 return the index of the key found, for instance to
> use it for setting/resetting the found element in the array?
That was just discussed. It's slightly faster not to return an index.
thread? Aside from that, I plan to commit this
week unless there is further bikeshedding.
--
John Naylor
EDB: http://www.enterprisedb.com
mes for
slower animals, even if Noah reported this didn't help the issue
upthread. I suspect it wouldn't slow down production use much since
the output needs to be compiled anyway.
--
John Naylor
EDB: http://www.enterprisedb.com
On Thu, Aug 4, 2022 at 8:41 PM Tom Lane wrote:
>
> John Naylor writes:
> > RepOriginId is a typedef for uint16, so this can't print the wrong
answer,
> > but it is inconsistent with other uses. So it seems we don't need to
> > backpatch this one?
>
> Um ..
On Fri, Aug 5, 2022 at 5:15 AM Nathan Bossart
wrote:
>
> On Thu, Aug 04, 2022 at 02:58:14PM +0700, John Naylor wrote:
> > Were you considering adding the new function to simd.h now that that's
> > committed? It's a bit up in the air what should go in there, but this
new
> &g
002, the whitespace issue in the top comment in inval.c, I'm
inclined to just change all the out-of-place tabs in a single commit, so we
can add that to the list of whitespace commits.
--
John Naylor
EDB: http://www.enterprisedb.com
;depends" to "depend" here is incorrect. Maybe we
> can say something like:
>
> the DEPENDS ON EXTENSION
> extension_name action
>
> (I haven't tested whether this markup works.)
Makes sense, I'll go make it happen.
--
John Naylor
EDB: http://www.enterprisedb.com
"_int" vs "_byte"?).
I'm not a fan of "its" as a variable name, and I'm curious what it's
intended to convey.
All the __m128i vars could technically be declared const, although I think
it doesn't matter -- it's just a hint to the reader.
Out of curiosity do we know how
On Thu, Aug 4, 2022 at 12:38 PM Masahiko Sawada
wrote:
>
> I also think it's a good start. There is a typo in the commit message:
>
> s/hepler/helper/
>
> The rest looks good to me.
Fixed, and pushed, thanks to you both! I'll polish a small patch I have
that actually uses thi
of those callers will rarely have more than several elements to
search in the first place, or aren't performance-sensitive.
--
John Naylor
EDB: http://www.enterprisedb.com
ly important to keep an eye on the buildfarm when this change is
> committed.
Thanks for checking! Here's a concrete patch for testing.
--
John Naylor
EDB: http://www.enterprisedb.com
From 0e01cc8f5f1c2c27631953091a1d657c5e5486be Mon Sep 17 00:00:00 2001
From: John Naylor
Date: Wed, 3 Aug 2022
other files, and would be the place to put helper
functions. Thoughts?
[1] https://docs.microsoft.com/en-us/archive/blogs/reiley/macro-revisited
[2]
https://stackoverflow.com/questions/56049110/including-the-correct-intrinsic-header
--
John Naylor
EDB: http://www.enterprisedb.com
space, as is customary? The rest LGTM.
--
John Naylor
EDB: http://www.enterprisedb.com
epends on extension action), to be dropped as well.
+ that depend on extension action), to be dropped as well.
--
John Naylor
EDB: http://www.enterprisedb.com
On Mon, Aug 1, 2022 at 9:16 PM Tom Lane wrote:
>
> John Naylor writes:
> > You are correct, but I wonder if it'd be better to just drop the comment
> > entirely. I checked a couple other random headers with function
> > declarations and they didn't have such a comment,
ignal
> procsignal sinvaladt logtape rangetypes
I was talking only about catalog/pg_*.c functions, as in Japin Li's latest
patch. You didn't mention whether your examples fall in the category Tom
mentioned upthread, so I'm not sure what your angle is.
--
John Naylor
EDB: http://www.enterprisedb.com
didn't have such a comment, and it's kind of obvious
what they're for.
--
John Naylor
EDB: http://www.enterprisedb.com
sary, but it was sufficient and already present, so I borrowed
it for the PoC.
--
John Naylor
EDB: http://www.enterprisedb.com
On Tue, Jul 19, 2022 at 10:57 PM Andres Freund wrote:
>
> Hi,
>
> On 2022-07-19 14:30:34 +0700, John Naylor wrote:
> > I'm thinking where the first few attributes are fixed length, not null,
and
> > (because of AIX) not double-aligned, we can do a single memcpy on
mult
On Thu, Jul 21, 2022 at 11:22 AM Kyotaro Horiguchi
wrote:
>
> At Thu, 21 Jul 2022 10:20:30 +0700, John Naylor <
john.nay...@enterprisedb.com> wrote in
> > On Wed, Jul 20, 2022 at 3:40 PM Kyotaro Horiguchi <
horikyota@gmail.com>
> > wrote:
> > > By the w
erence, but in any case I
don't see a slowdown anywhere.
[1]
https://www.postgresql.org/message-id/CAFBsxsHeTACMP1JVQ%2Bm35-v2NkmEqsJMHLhEfWk4sTB5aw_jkQ%40mail.gmail.com
--
John Naylor
EDB: http://www.enterprisedb.com
master-vs-custom-ext-v2.ods
Description: application/vnd.oasis.opendocument.spreadsheet
and I
just forgot to consider that.
--
John Naylor
EDB: http://www.enterprisedb.com
lper functions/macros similar to the above but
instead of passing a tuple descriptor, use info we have at compile time.
--
John Naylor
EDB: http://www.enterprisedb.com
example.
These two aspects would also bring it closer to Andres' prototype, which 1)
makes review easier and 2) easier to preserve optimization work already
done, so +1 from me.
--
John Naylor
EDB: http://www.enterprisedb.com
think it's way too much to ask for the first use case.
--
John Naylor
EDB: http://www.enterprisedb.com
Hm. Wouldn't it make sense to just use the normal tuple deforming
routines and
> then map the results to the structs?
I wasn't sure if they'd be suitable for this, but if they are, that'd make
this easier and more maintainable. I'll look into it.
--
John Naylor
EDB: http://www.enterprisedb.com
he chance of different
patches conflicting with each other. It doesn't really matter what the oid
here is, since at feature freeze a committer will change them anyway.
--
John Naylor
EDB: http://www.enterprisedb.com
way, in this thread
https://www.postgresql.org/message-id/CA%2BhUKGKztHEWm676csTFjYzortziWmOcf8HDss2Zr0muZ2xfEg%40mail.gmail.com
where you may find this patch
https://www.postgresql.org/message-id/attachment/120560/0007-Specialize-pagetable-sort-routines-in-tidbitmap.c.patch
and see if it helps.
--
J
resql.org/message-id/1178821226.6034.63.camel@goldbach
Did we already have a hash lookup for IN clauses with constants and the
above commit adds NOT IN? If so, maybe we have enough to remove this todo
item.
--
John Naylor
EDB: http://www.enterprisedb.com
an extra field to track the role OID in one of the GUC
> structs or in one of its API arguments, that's fine by me.
>
> If this requires more work, a revert can of course be discussed, but I
> am not getting that this is really necessary here. This would be the
> last option to consider
e of time to get tied up about the fine details of
something that will not likely happen for several years at the
earliest.
--
John Naylor
EDB: http://www.enterprisedb.com
me library)
there is no FREE cursor_name statement in ECPG.
This is because in ECPG,
DECLARE CURSOR doesn't translate to a function
call into
I've pushed that in addition to your changes, thanks!
--
John Naylor
EDB: http://www.enterprisedb.com
501 - 600 of 1339 matches
Mail list logo
