agora inbox for [email protected]
help / color / mirror / Atom feed[PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour
15+ messages / 4 participants
[nested] [flat]
* [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour
@ 2021-01-13 11:05 Bharath Rupireddy <[email protected]>
0 siblings, 0 replies; 15+ messages in thread
From: Bharath Rupireddy @ 2021-01-13 11:05 UTC (permalink / raw)
Currently, in logical replication, publisher/walsender publishes
the tables even though they aren't part of the publication i.e
they are dropped from the publication. Because of this ALTER
PUBLICATION...DROP TABLE doesn't work as expected.
---
src/backend/replication/pgoutput/pgoutput.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 2f01137b42..118faf6ce3 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -1179,5 +1179,18 @@ rel_sync_cache_publication_cb(Datum arg, int cacheid, uint32 hashvalue)
*/
hash_seq_init(&status, RelationSyncCache);
while ((entry = (RelationSyncEntry *) hash_seq_search(&status)) != NULL)
+ {
entry->replicate_valid = false;
+
+ /*
+ * There might some relations dropped from the publication, we do
+ * not need to publish the changes for them. However, we cannot get
+ * the dropped relations (see above), so we reset pubactions for all
+ * entries.
+ */
+ entry->pubactions.pubinsert = false;
+ entry->pubactions.pubupdate = false;
+ entry->pubactions.pubdelete = false;
+ entry->pubactions.pubtruncate = false;
+ }
}
--
2.30.0
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=v3-0002-Invalidate-relation-map-cache-in-subscriber-sysca.patch
^ permalink raw reply [nested|flat] 15+ messages in thread
* macos ventura SDK spews warnings
@ 2022-10-15 21:19 Andres Freund <[email protected]>
0 siblings, 2 replies; 15+ messages in thread
From: Andres Freund @ 2022-10-15 21:19 UTC (permalink / raw)
To: pgsql-hackers
Hi
I had recently updated the M1 mini that I use to test macOS stuff on. Just
tried to test a change on it and was greeted with a lot of
warnings. Apparently the update brought in a newer SDK (MacOSX13.0.sdk), even
though the OS is still Monterey.
One class of warnings is specific to meson (see further down), but the other
is common between autoconf and meson:
[24/2258] Compiling C object src/port/libpgport_srv.a.p/snprintf.c.o
../../../src/postgres/src/port/snprintf.c:1002:11: warning: 'sprintf' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Wdeprecated-declarations]
vallen = sprintf(convert, "%p", value);
^
/Library/Developer/CommandLineTools/SDKs/MacOSX13.0.sdk/usr/include/stdio.h:188:1: note: 'sprintf' has been explicitly marked deprecated here
__deprecated_msg("This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead.")
^
/Library/Developer/CommandLineTools/SDKs/MacOSX13.0.sdk/usr/include/sys/cdefs.h:215:48: note: expanded from macro '__deprecated_msg'
#define __deprecated_msg(_msg) __attribute__((__deprecated__(_msg)))
^
the same warning is repeated for a bunch of different lines in the same file,
and then over the three versions of libpgport that we build.
This is pretty noisy.
The meson specific warning is
[972/1027] Linking target src/backend/replication/libpqwalreceiver/libpqwalreceiver.dylib
ld: warning: -undefined dynamic_lookup may not work with chained fixups
Which is caused by meson defaulting to -Wl,-undefined,dynamic_lookup for
modules. But we don't need that because we use -bund-loader. Adding
-Wl,-undefined,error as in the attached fixes it.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: macos ventura SDK spews warnings
@ 2022-10-15 21:56 Tom Lane <[email protected]>
parent: Andres Freund <[email protected]>
1 sibling, 1 reply; 15+ messages in thread
From: Tom Lane @ 2022-10-15 21:56 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: pgsql-hackers
Andres Freund <[email protected]> writes:
> One class of warnings is specific to meson (see further down), but the other
> is common between autoconf and meson:
> [24/2258] Compiling C object src/port/libpgport_srv.a.p/snprintf.c.o
> ../../../src/postgres/src/port/snprintf.c:1002:11: warning: 'sprintf' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Wdeprecated-declarations]
> vallen = sprintf(convert, "%p", value);
> ^
Originally we used the platform's sprintf there because we couldn't
rely on platforms having functional snprintf. That's no longer the case,
I imagine, so we could just switch these calls over to snprintf. I'm
kind of surprised that we haven't already been getting the likes of
this warning from, eg, OpenBSD.
Note that the hundreds of other sprintf calls in our code are actually
calling pg_sprintf, which hasn't got a deprecation label. But the ones
in snprintf.c are really trying to call the platform's version.
(I wonder how much we ought to worry about bugs in the pg_sprintf usages?
But that's a matter for another day and another thread.)
regards, tom lane
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: macos ventura SDK spews warnings
@ 2022-10-15 22:47 Tom Lane <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Tom Lane @ 2022-10-15 22:47 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: pgsql-hackers
I wrote:
> Andres Freund <[email protected]> writes:
>> [24/2258] Compiling C object src/port/libpgport_srv.a.p/snprintf.c.o
>> ../../../src/postgres/src/port/snprintf.c:1002:11: warning: 'sprintf' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Wdeprecated-declarations]
> Originally we used the platform's sprintf there because we couldn't
> rely on platforms having functional snprintf. That's no longer the case,
> I imagine, so we could just switch these calls over to snprintf. I'm
> kind of surprised that we haven't already been getting the likes of
> this warning from, eg, OpenBSD.
The attached seems enough to silence it for me.
Should we back-patch this? I suppose, but how far? It seems to fall
under the rules we established for back-patching into out-of-support
branches, ie it silences compiler warnings but shouldn't change any
behavior. But it feels like a bigger change than most of the other
things we've done that with.
regards, tom lane
Attachments:
[text/x-diff] remove-last-uses-of-sprintf.patch (2.1K, ../../[email protected]/2-remove-last-uses-of-sprintf.patch)
download | inline diff:
diff --git a/src/port/snprintf.c b/src/port/snprintf.c
index e037cf0a88..81d9c8c274 100644
--- a/src/port/snprintf.c
+++ b/src/port/snprintf.c
@@ -998,8 +998,8 @@ fmtptr(const void *value, PrintfTarget *target)
int vallen;
char convert[64];
- /* we rely on regular C library's sprintf to do the basic conversion */
- vallen = sprintf(convert, "%p", value);
+ /* we rely on regular C library's snprintf to do the basic conversion */
+ vallen = snprintf(convert, sizeof(convert), "%p", value);
if (vallen < 0)
target->failed = true;
else
@@ -1149,11 +1149,11 @@ fmtfloat(double value, char type, int forcesign, int leftjust,
int padlen; /* amount to pad with spaces */
/*
- * We rely on the regular C library's sprintf to do the basic conversion,
+ * We rely on the regular C library's snprintf to do the basic conversion,
* then handle padding considerations here.
*
* The dynamic range of "double" is about 1E+-308 for IEEE math, and not
- * too wildly more than that with other hardware. In "f" format, sprintf
+ * too wildly more than that with other hardware. In "f" format, snprintf
* could therefore generate at most 308 characters to the left of the
* decimal point; while we need to allow the precision to get as high as
* 308+17 to ensure that we don't truncate significant digits from very
@@ -1205,14 +1205,14 @@ fmtfloat(double value, char type, int forcesign, int leftjust,
fmt[2] = '*';
fmt[3] = type;
fmt[4] = '\0';
- vallen = sprintf(convert, fmt, prec, value);
+ vallen = snprintf(convert, sizeof(convert), fmt, prec, value);
}
else
{
fmt[0] = '%';
fmt[1] = type;
fmt[2] = '\0';
- vallen = sprintf(convert, fmt, value);
+ vallen = snprintf(convert, sizeof(convert), fmt, value);
}
if (vallen < 0)
goto fail;
@@ -1341,7 +1341,7 @@ pg_strfromd(char *str, size_t count, int precision, double value)
fmt[2] = '*';
fmt[3] = 'g';
fmt[4] = '\0';
- vallen = sprintf(convert, fmt, precision, value);
+ vallen = snprintf(convert, sizeof(convert), fmt, precision, value);
if (vallen < 0)
{
target.failed = true;
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: macos ventura SDK spews warnings
@ 2022-10-15 23:50 Andres Freund <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Andres Freund @ 2022-10-15 23:50 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: pgsql-hackers
Hi,
On 2022-10-15 18:47:16 -0400, Tom Lane wrote:
> I wrote:
> > Andres Freund <[email protected]> writes:
> >> [24/2258] Compiling C object src/port/libpgport_srv.a.p/snprintf.c.o
> >> ../../../src/postgres/src/port/snprintf.c:1002:11: warning: 'sprintf' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Wdeprecated-declarations]
>
> > Originally we used the platform's sprintf there because we couldn't
> > rely on platforms having functional snprintf. That's no longer the case,
> > I imagine, so we could just switch these calls over to snprintf. I'm
> > kind of surprised that we haven't already been getting the likes of
> > this warning from, eg, OpenBSD.
Is there a platform still supported in older branches that we need to worry
about?
> The attached seems enough to silence it for me.
>
> Should we back-patch this?
Probably, but not sure either. We could just let it stew in HEAD for a while.
> I suppose, but how far? It seems to fall under the rules we established for
> back-patching into out-of-support branches, ie it silences compiler warnings
> but shouldn't change any behavior. But it feels like a bigger change than
> most of the other things we've done that with.
I wonder if we ought to add -Wno-deprecated to out-of-support branches to deal
with this kind of thing...
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: macos ventura SDK spews warnings
@ 2022-10-16 00:08 Tom Lane <[email protected]>
parent: Andres Freund <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Tom Lane @ 2022-10-16 00:08 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: pgsql-hackers
Andres Freund <[email protected]> writes:
> On 2022-10-15 18:47:16 -0400, Tom Lane wrote:
>>> Originally we used the platform's sprintf there because we couldn't
>>> rely on platforms having functional snprintf. That's no longer the case,
>>> I imagine, so we could just switch these calls over to snprintf.
> Is there a platform still supported in older branches that we need to worry
> about?
snprintf is required by POSIX going back to SUSv2, so it's pretty darn
hard to imagine any currently-used platform that hasn't got it. Even
my now-extinct dinosaur gaur had it (per digging in backup files).
I think we could certainly assume its presence in the branches that
require C99. Even before that, is anybody really still building on
nineties-vintage platforms?
> I wonder if we ought to add -Wno-deprecated to out-of-support branches to deal
> with this kind of thing...
Yeah, that might be a better answer than playing whack-a-mole with
these sorts of warnings.
regards, tom lane
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: macos ventura SDK spews warnings
@ 2022-10-16 00:14 Andres Freund <[email protected]>
parent: Andres Freund <[email protected]>
1 sibling, 0 replies; 15+ messages in thread
From: Andres Freund @ 2022-10-16 00:14 UTC (permalink / raw)
To: pgsql-hackers
On 2022-10-15 14:19:55 -0700, Andres Freund wrote:
> The meson specific warning is
> [972/1027] Linking target src/backend/replication/libpqwalreceiver/libpqwalreceiver.dylib
> ld: warning: -undefined dynamic_lookup may not work with chained fixups
>
> Which is caused by meson defaulting to -Wl,-undefined,dynamic_lookup for
> modules. But we don't need that because we use -bund-loader. Adding
> -Wl,-undefined,error as in the attached fixes it.
Pushed the patch for that.
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: macos ventura SDK spews warnings
@ 2022-10-16 01:00 Tom Lane <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Tom Lane @ 2022-10-16 01:00 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: pgsql-hackers
I wrote:
> snprintf is required by POSIX going back to SUSv2, so it's pretty darn
> hard to imagine any currently-used platform that hasn't got it. Even
> my now-extinct dinosaur gaur had it (per digging in backup files).
> I think we could certainly assume its presence in the branches that
> require C99.
After further thought, I think the best compromise is just that:
(1) apply s/sprintf/snprintf/ patch in branches back to v12, where
we began to require C99.
(2) in v11 and back to 9.2, enable -Wno-deprecated if available.
One thing motivating this choice is that we're just a couple
weeks away from the final release of v10. So I'm hesitant to do
anything that might turn out to be moving the portability goalposts
in v10. But we're already assuming we can detect -Wno-foo options
correctly in v10 and older (e.g. 4c5a29c0e), so point (2) seems
pretty low-risk.
regards, tom lane
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: macos ventura SDK spews warnings
@ 2022-10-16 05:34 Andres Freund <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Andres Freund @ 2022-10-16 05:34 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: pgsql-hackers
Hi,
On 2022-10-15 21:00:00 -0400, Tom Lane wrote:
> I wrote:
> > snprintf is required by POSIX going back to SUSv2, so it's pretty darn
> > hard to imagine any currently-used platform that hasn't got it. Even
> > my now-extinct dinosaur gaur had it (per digging in backup files).
> > I think we could certainly assume its presence in the branches that
> > require C99.
>
> After further thought, I think the best compromise is just that:
>
> (1) apply s/sprintf/snprintf/ patch in branches back to v12, where
> we began to require C99.
>
> (2) in v11 and back to 9.2, enable -Wno-deprecated if available.
>
> One thing motivating this choice is that we're just a couple
> weeks away from the final release of v10. So I'm hesitant to do
> anything that might turn out to be moving the portability goalposts
> in v10. But we're already assuming we can detect -Wno-foo options
> correctly in v10 and older (e.g. 4c5a29c0e), so point (2) seems
> pretty low-risk.
Makes sense to me.
- Andres
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: macos ventura SDK spews warnings
@ 2022-10-16 16:40 Tom Lane <[email protected]>
parent: Andres Freund <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Tom Lane @ 2022-10-16 16:40 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: pgsql-hackers
Andres Freund <[email protected]> writes:
> On 2022-10-15 21:00:00 -0400, Tom Lane wrote:
>> After further thought, I think the best compromise is just that:
>>
>> (1) apply s/sprintf/snprintf/ patch in branches back to v12, where
>> we began to require C99.
>>
>> (2) in v11 and back to 9.2, enable -Wno-deprecated if available.
> Makes sense to me.
I remembered another reason why v12 should be a cutoff: it's where
we started to use snprintf.c everywhere. In prior branches, there'd
be a lot of complaints about sprintf elsewhere in the tree.
So I pushed (1), but on the way to testing (2), I discovered a totally
independent problem with the 13.0 SDK in older branches:
In file included from ../../../src/include/postgres.h:46:
In file included from ../../../src/include/c.h:1387:
In file included from ../../../src/include/port.h:17:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX13.0.sdk/usr/include/netdb.h:91:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX13.0.sdk/usr/include/netinet/in.h:81:
/Library/Developer/CommandLineTools/SDKs/MacOSX13.0.sdk/usr/include/sys/socket.h:471:1: error: expected ';' after top level declarator
__CCT_DECLARE_CONSTRAINED_PTR_TYPES(struct sockaddr_storage, sockaddr_storage);
^
This is apparently some sort of inclusion-order problem, which is probably
a bug in the SDK --- netdb.h and netinet/in.h are the same as they were in
SDK 12.3, but sys/socket.h has a few additions including this
__CCT_DECLARE_CONSTRAINED_PTR_TYPES macro, and evidently that's missing
something it needs. I haven't traced down the cause of the problem yet.
It fails to manifest in v15 and HEAD, which I bisected to
98e93a1fc93e9b54eb477d870ec744e9e1669f34 is the first new commit
commit 98e93a1fc93e9b54eb477d870ec744e9e1669f34
Author: Tom Lane <[email protected]>
Date: Tue Jan 11 13:46:12 2022 -0500
Clean up messy API for src/port/thread.c.
The point of this patch is to reduce inclusion spam by not needing
to #include <netdb.h> or <pwd.h> in port.h (which is read by every
compile in our tree). To do that, we must remove port.h's
declarations of pqGetpwuid and pqGethostbyname.
I doubt we want to back-patch that, so what we'll probably end up with
is adding some #includes to port.h in the back branches. Bleah.
Or we could file a bug with Apple and hope they fix it quickly.
(They might, actually, because this SDK is supposedly beta.)
regards, tom lane
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: macos ventura SDK spews warnings
@ 2022-10-16 17:35 Tom Lane <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Tom Lane @ 2022-10-16 17:35 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: pgsql-hackers
I wrote:
> So I pushed (1), but on the way to testing (2), I discovered a totally
> independent problem with the 13.0 SDK in older branches:
> In file included from ../../../src/include/postgres.h:46:
> In file included from ../../../src/include/c.h:1387:
> In file included from ../../../src/include/port.h:17:
> In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX13.0.sdk/usr/include/netdb.h:91:
> In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX13.0.sdk/usr/include/netinet/in.h:81:
> /Library/Developer/CommandLineTools/SDKs/MacOSX13.0.sdk/usr/include/sys/socket.h:471:1: error: expected ';' after top level declarator
> __CCT_DECLARE_CONSTRAINED_PTR_TYPES(struct sockaddr_storage, sockaddr_storage);
> ^
Ah, I see it. This is not failing everywhere, only in gram.y and
associated files, and it happens because those have a #define for REF,
which is breaking this constrained_ctypes stuff:
/Library/Developer/CommandLineTools/SDKs/MacOSX13.0.sdk/usr/include/sys/socket.h:471:1: error: expected ';' after top level declarator
__CCT_DECLARE_CONSTRAINED_PTR_TYPES(struct sockaddr_storage, sockaddr_storage);
^
/Library/Developer/CommandLineTools/SDKs/MacOSX13.0.sdk/usr/include/sys/constrained_ctypes.h:588:101: note: expanded from macro '__CCT_DECLARE_CONSTRAINED_PTR_TYPES'
__CCT_DECLARE_CONSTRAINED_PTR_TYPE(basetype, basetag, REF); \
^
Now on the one hand Apple is pretty clearly violating user namespace
by using a name like "REF", and I'll go file a bug about that.
On the other hand, #defining something like "REF" isn't very bright
on our part either. We usually write something like REF_P when
there is a danger of parser tokens colliding with other names.
I think the correct, future-proof fix is to s/REF/REF_P/ in the
grammar. We'll have to back-patch that, too, unless we want to
change what port.h includes. I found that an alternative possible
band-aid is to do this in port.h:
diff --git a/src/include/port.h b/src/include/port.h
index b405d0e740..416428a0d2 100644
--- a/src/include/port.h
+++ b/src/include/port.h
@@ -14,7 +14,6 @@
#define PG_PORT_H
#include <ctype.h>
-#include <netdb.h>
#include <pwd.h>
/*
@@ -491,6 +490,8 @@ extern int pqGetpwuid(uid_t uid, struct passwd *resultbuf, char *buffer,
size_t buflen, struct passwd **result);
#endif
+struct hostent; /* avoid including <netdb.h> here */
+
extern int pqGethostbyname(const char *name,
struct hostent *resultbuf,
char *buffer, size_t buflen,
but it seems like there's a nonzero risk that some third-party
code somewhere is depending on our having included <netdb.h> here.
So ceasing to do that in the back branches doesn't seem great.
Changing a parser token name in the back branches isn't ideal
either, but it seems less risky to me than removing a globally
visible #include.
regards, tom lane
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: macos ventura SDK spews warnings
@ 2022-10-16 20:45 Tom Lane <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Tom Lane @ 2022-10-16 20:45 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: pgsql-hackers
I wrote:
> I think the correct, future-proof fix is to s/REF/REF_P/ in the
> grammar.
Done like that, after which I found that the pre-v12 branches are
compiling perfectly warning-free with the 13.0 SDK, despite nothing
having been done about sprintf. This confused me mightily, but
after digging in Apple's headers I understand it. What actually
gets provided by <stdio.h> is a declaration of sprintf(), now
with deprecation attribute attached, followed awhile later by
#if __has_builtin(__builtin___sprintf_chk) || defined(__GNUC__)
extern int __sprintf_chk (char * __restrict, int, size_t,
const char * __restrict, ...);
#undef sprintf
#define sprintf(str, ...) \
__builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
#endif
So in the ordinary course of events, calling sprintf() results in
calling this non-deprecated builtin. Only if you "#undef sprintf"
will you see the deprecation message. snprintf.c does that, so
we see the message when that's built. But if we don't use snprintf.c,
as the older branches do not on macOS, we don't ever #undef sprintf.
So for now, there seems no need for -Wno-deprecated, and I'm not
going to install it.
What I *am* seeing, in the 9.5 and 9.6 branches, is a ton of
ld: warning: -undefined dynamic_lookup may not work with chained fixups
apparently because we are specifying -Wl,-undefined,dynamic_lookup
which the other branches don't do. That's kind of annoying,
but it looks like preventing that would be way too invasive :-(.
We'd added it to un-break some cases in the contrib transform
modules, and we didn't have a better solution until v10 [1].
regards, tom lane
[1] https://www.postgresql.org/message-id/2652.1475512158%40sss.pgh.pa.us
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: macos ventura SDK spews warnings
@ 2022-10-16 21:59 Andres Freund <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Andres Freund @ 2022-10-16 21:59 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: pgsql-hackers
Hi,
On 2022-10-16 16:45:24 -0400, Tom Lane wrote:
> I wrote:
> > I think the correct, future-proof fix is to s/REF/REF_P/ in the
> > grammar.
>
> Done like that, after which I found that the pre-v12 branches are
> compiling perfectly warning-free with the 13.0 SDK, despite nothing
> having been done about sprintf. This confused me mightily, but
> after digging in Apple's headers I understand it. What actually
> gets provided by <stdio.h> is a declaration of sprintf(), now
> with deprecation attribute attached, followed awhile later by
>
> #if __has_builtin(__builtin___sprintf_chk) || defined(__GNUC__)
> extern int __sprintf_chk (char * __restrict, int, size_t,
> const char * __restrict, ...);
>
> #undef sprintf
> #define sprintf(str, ...) \
> __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
> #endif
>
> So in the ordinary course of events, calling sprintf() results in
> calling this non-deprecated builtin. Only if you "#undef sprintf"
> will you see the deprecation message.
Oh, huh. That's an odd setup... It's not like the the object size stuff
provides reliable protection.
> What I *am* seeing, in the 9.5 and 9.6 branches, is a ton of
>
> ld: warning: -undefined dynamic_lookup may not work with chained fixups
>
> apparently because we are specifying -Wl,-undefined,dynamic_lookup
> which the other branches don't do. That's kind of annoying,
> but it looks like preventing that would be way too invasive :-(.
> We'd added it to un-break some cases in the contrib transform
> modules, and we didn't have a better solution until v10 [1].
Hm - I think it might actually mean that transforms won't work with the new
macos relocation format, which is what I understand "chained fixups" to be.
Unfortunately it looks like the chained fixup stuff is enabled even when
targetting Monterey, even though it was only introduced with the 13 sdk (I
think). But it does look like using the macos 11 SDK sysroot does force the
use of the older relocation format. So we have at least some way out :/
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: macos ventura SDK spews warnings
@ 2022-10-16 22:29 Tom Lane <[email protected]>
parent: Andres Freund <[email protected]>
0 siblings, 0 replies; 15+ messages in thread
From: Tom Lane @ 2022-10-16 22:29 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: pgsql-hackers
Andres Freund <[email protected]> writes:
> On 2022-10-16 16:45:24 -0400, Tom Lane wrote:
>> What I *am* seeing, in the 9.5 and 9.6 branches, is a ton of
>>
>> ld: warning: -undefined dynamic_lookup may not work with chained fixups
>>
>> apparently because we are specifying -Wl,-undefined,dynamic_lookup
>> which the other branches don't do. That's kind of annoying,
>> but it looks like preventing that would be way too invasive :-(.
>> We'd added it to un-break some cases in the contrib transform
>> modules, and we didn't have a better solution until v10 [1].
> Hm - I think it might actually mean that transforms won't work with the new
> macos relocation format, which is what I understand "chained fixups" to be.
Hm ... hstore_plpython and ltree_plpython still pass regression check in
9.6, so it works for at least moderate-size values of "work", at least on
Monterey. But in any case, if there's a problem there I can't see us
doing anything about that in dead branches. The "keep it building" rule
doesn't extend to perl or python dependencies IMO.
regards, tom lane
^ permalink raw reply [nested|flat] 15+ messages in thread
* [PATCH v11 1/7] Row pattern recognition patch for raw parser.
@ 2023-11-08 06:57 Tatsuo Ishii <[email protected]>
0 siblings, 0 replies; 15+ messages in thread
From: Tatsuo Ishii @ 2023-11-08 06:57 UTC (permalink / raw)
---
src/backend/parser/gram.y | 222 ++++++++++++++++++++++++++++++--
src/include/nodes/parsenodes.h | 56 ++++++++
src/include/parser/kwlist.h | 8 ++
src/include/parser/parse_node.h | 1 +
4 files changed, 273 insertions(+), 14 deletions(-)
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index c224df4ecc..e09eb061f8 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -251,6 +251,8 @@ static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
DefElem *defelt;
SortBy *sortby;
WindowDef *windef;
+ RPCommonSyntax *rpcom;
+ RPSubsetItem *rpsubset;
JoinExpr *jexpr;
IndexElem *ielem;
StatsElem *selem;
@@ -278,6 +280,7 @@ static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
MergeWhenClause *mergewhen;
struct KeyActions *keyactions;
struct KeyAction *keyaction;
+ RPSkipTo skipto;
}
%type <node> stmt toplevel_stmt schema_stmt routine_body_stmt
@@ -453,8 +456,12 @@ static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
TriggerTransitions TriggerReferencing
vacuum_relation_list opt_vacuum_relation_list
drop_option_list pub_obj_list
-
-%type <node> opt_routine_body
+ row_pattern_measure_list row_pattern_definition_list
+ opt_row_pattern_subset_clause
+ row_pattern_subset_list row_pattern_subset_rhs
+ row_pattern
+%type <rpsubset> row_pattern_subset_item
+%type <node> opt_routine_body row_pattern_term
%type <groupclause> group_clause
%type <list> group_by_list
%type <node> group_by_item empty_grouping_set rollup_clause cube_clause
@@ -551,6 +558,8 @@ static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
%type <range> relation_expr_opt_alias
%type <node> tablesample_clause opt_repeatable_clause
%type <target> target_el set_target insert_column_item
+ row_pattern_measure_item row_pattern_definition
+%type <skipto> first_or_last
%type <str> generic_option_name
%type <node> generic_option_arg
@@ -633,6 +642,9 @@ static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
%type <list> window_clause window_definition_list opt_partition_clause
%type <windef> window_definition over_clause window_specification
opt_frame_clause frame_extent frame_bound
+%type <rpcom> opt_row_pattern_common_syntax opt_row_pattern_skip_to
+%type <boolean> opt_row_pattern_initial_or_seek
+%type <list> opt_row_pattern_measures
%type <ival> opt_window_exclusion_clause
%type <str> opt_existing_window_name
%type <boolean> opt_if_not_exists
@@ -659,7 +671,6 @@ static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
json_object_constructor_null_clause_opt
json_array_constructor_null_clause_opt
-
/*
* Non-keyword token types. These are hard-wired into the "flex" lexer.
* They must be listed first so that their numeric codes do not depend on
@@ -702,7 +713,7 @@ static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
CURRENT_TIME CURRENT_TIMESTAMP CURRENT_USER CURSOR CYCLE
DATA_P DATABASE DAY_P DEALLOCATE DEC DECIMAL_P DECLARE DEFAULT DEFAULTS
- DEFERRABLE DEFERRED DEFINER DELETE_P DELIMITER DELIMITERS DEPENDS DEPTH DESC
+ DEFERRABLE DEFERRED DEFINE DEFINER DELETE_P DELIMITER DELIMITERS DEPENDS DEPTH DESC
DETACH DICTIONARY DISABLE_P DISCARD DISTINCT DO DOCUMENT_P DOMAIN_P
DOUBLE_P DROP
@@ -718,7 +729,7 @@ static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
HANDLER HAVING HEADER_P HOLD HOUR_P
IDENTITY_P IF_P ILIKE IMMEDIATE IMMUTABLE IMPLICIT_P IMPORT_P IN_P INCLUDE
- INCLUDING INCREMENT INDENT INDEX INDEXES INHERIT INHERITS INITIALLY INLINE_P
+ INCLUDING INCREMENT INDENT INDEX INDEXES INHERIT INHERITS INITIAL INITIALLY INLINE_P
INNER_P INOUT INPUT_P INSENSITIVE INSERT INSTEAD INT_P INTEGER
INTERSECT INTERVAL INTO INVOKER IS ISNULL ISOLATION
@@ -731,7 +742,7 @@ static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
LEADING LEAKPROOF LEAST LEFT LEVEL LIKE LIMIT LISTEN LOAD LOCAL
LOCALTIME LOCALTIMESTAMP LOCATION LOCK_P LOCKED LOGGED
- MAPPING MATCH MATCHED MATERIALIZED MAXVALUE MERGE METHOD
+ MAPPING MATCH MATCHED MATERIALIZED MAXVALUE MEASURES MERGE METHOD
MINUTE_P MINVALUE MODE MONTH_P MOVE
NAME_P NAMES NATIONAL NATURAL NCHAR NEW NEXT NFC NFD NFKC NFKD NO NONE
@@ -743,8 +754,8 @@ static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
ORDER ORDINALITY OTHERS OUT_P OUTER_P
OVER OVERLAPS OVERLAY OVERRIDING OWNED OWNER
- PARALLEL PARAMETER PARSER PARTIAL PARTITION PASSING PASSWORD
- PLACING PLANS POLICY
+ PARALLEL PARAMETER PARSER PARTIAL PARTITION PASSING PASSWORD PAST
+ PATTERN_P PERMUTE PLACING PLANS POLICY
POSITION PRECEDING PRECISION PRESERVE PREPARE PREPARED PRIMARY
PRIOR PRIVILEGES PROCEDURAL PROCEDURE PROCEDURES PROGRAM PUBLICATION
@@ -755,12 +766,13 @@ static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
RESET RESTART RESTRICT RETURN RETURNING RETURNS REVOKE RIGHT ROLE ROLLBACK ROLLUP
ROUTINE ROUTINES ROW ROWS RULE
- SAVEPOINT SCALAR SCHEMA SCHEMAS SCROLL SEARCH SECOND_P SECURITY SELECT
+ SAVEPOINT SCALAR SCHEMA SCHEMAS SCROLL SEARCH SECOND_P SECURITY SEEK SELECT
SEQUENCE SEQUENCES
+
SERIALIZABLE SERVER SESSION SESSION_USER SET SETS SETOF SHARE SHOW
SIMILAR SIMPLE SKIP SMALLINT SNAPSHOT SOME SQL_P STABLE STANDALONE_P
START STATEMENT STATISTICS STDIN STDOUT STORAGE STORED STRICT_P STRIP_P
- SUBSCRIPTION SUBSTRING SUPPORT SYMMETRIC SYSID SYSTEM_P SYSTEM_USER
+ SUBSCRIPTION SUBSET SUBSTRING SUPPORT SYMMETRIC SYSID SYSTEM_P SYSTEM_USER
TABLE TABLES TABLESAMPLE TABLESPACE TEMP TEMPLATE TEMPORARY TEXT_P THEN
TIES TIME TIMESTAMP TO TRAILING TRANSACTION TRANSFORM
@@ -853,6 +865,7 @@ static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
*/
%nonassoc UNBOUNDED /* ideally would have same precedence as IDENT */
%nonassoc IDENT PARTITION RANGE ROWS GROUPS PRECEDING FOLLOWING CUBE ROLLUP
+%nonassoc MEASURES AFTER INITIAL SEEK PATTERN_P
%left Op OPERATOR /* multi-character ops and user-defined operators */
%left '+' '-'
%left '*' '/' '%'
@@ -15901,7 +15914,8 @@ over_clause: OVER window_specification
;
window_specification: '(' opt_existing_window_name opt_partition_clause
- opt_sort_clause opt_frame_clause ')'
+ opt_sort_clause opt_row_pattern_measures opt_frame_clause
+ opt_row_pattern_common_syntax ')'
{
WindowDef *n = makeNode(WindowDef);
@@ -15909,10 +15923,12 @@ window_specification: '(' opt_existing_window_name opt_partition_clause
n->refname = $2;
n->partitionClause = $3;
n->orderClause = $4;
+ n->rowPatternMeasures = $5;
/* copy relevant fields of opt_frame_clause */
- n->frameOptions = $5->frameOptions;
- n->startOffset = $5->startOffset;
- n->endOffset = $5->endOffset;
+ n->frameOptions = $6->frameOptions;
+ n->startOffset = $6->startOffset;
+ n->endOffset = $6->endOffset;
+ n->rpCommonSyntax = $7;
n->location = @1;
$$ = n;
}
@@ -15936,6 +15952,31 @@ opt_partition_clause: PARTITION BY expr_list { $$ = $3; }
| /*EMPTY*/ { $$ = NIL; }
;
+/*
+ * ROW PATTERN_P MEASURES
+ */
+opt_row_pattern_measures: MEASURES row_pattern_measure_list { $$ = $2; }
+ | /*EMPTY*/ { $$ = NIL; }
+ ;
+
+row_pattern_measure_list:
+ row_pattern_measure_item
+ { $$ = list_make1($1); }
+ | row_pattern_measure_list ',' row_pattern_measure_item
+ { $$ = lappend($1, $3); }
+ ;
+
+row_pattern_measure_item:
+ a_expr AS ColLabel
+ {
+ $$ = makeNode(ResTarget);
+ $$->name = $3;
+ $$->indirection = NIL;
+ $$->val = (Node *) $1;
+ $$->location = @1;
+ }
+ ;
+
/*
* For frame clauses, we return a WindowDef, but only some fields are used:
* frameOptions, startOffset, and endOffset.
@@ -16095,6 +16136,143 @@ opt_window_exclusion_clause:
| /*EMPTY*/ { $$ = 0; }
;
+opt_row_pattern_common_syntax:
+opt_row_pattern_skip_to opt_row_pattern_initial_or_seek
+ PATTERN_P '(' row_pattern ')'
+ opt_row_pattern_subset_clause
+ DEFINE row_pattern_definition_list
+ {
+ RPCommonSyntax *n = makeNode(RPCommonSyntax);
+ n->rpSkipTo = $1->rpSkipTo;
+ n->rpSkipVariable = $1->rpSkipVariable;
+ n->initial = $2;
+ n->rpPatterns = $5;
+ n->rpSubsetClause = $7;
+ n->rpDefs = $9;
+ $$ = n;
+ }
+ | /*EMPTY*/ { $$ = NULL; }
+ ;
+
+opt_row_pattern_skip_to:
+ AFTER MATCH SKIP TO NEXT ROW
+ {
+ RPCommonSyntax *n = makeNode(RPCommonSyntax);
+ n->rpSkipTo = ST_NEXT_ROW;
+ n->rpSkipVariable = NULL;
+ $$ = n;
+ }
+ | AFTER MATCH SKIP PAST LAST_P ROW
+ {
+ RPCommonSyntax *n = makeNode(RPCommonSyntax);
+ n->rpSkipTo = ST_PAST_LAST_ROW;
+ n->rpSkipVariable = NULL;
+ $$ = n;
+ }
+ | AFTER MATCH SKIP TO first_or_last ColId
+ {
+ RPCommonSyntax *n = makeNode(RPCommonSyntax);
+ n->rpSkipTo = $5;
+ n->rpSkipVariable = $6;
+ $$ = n;
+ }
+/*
+ | AFTER MATCH SKIP TO LAST_P ColId %prec LAST_P
+ {
+ RPCommonSyntax *n = makeNode(RPCommonSyntax);
+ n->rpSkipTo = ST_LAST_VARIABLE;
+ n->rpSkipVariable = $6;
+ $$ = n;
+ }
+ | AFTER MATCH SKIP TO ColId
+ {
+ RPCommonSyntax *n = makeNode(RPCommonSyntax);
+ n->rpSkipTo = ST_VARIABLE;
+ n->rpSkipVariable = $5;
+ $$ = n;
+ }
+*/
+ | /*EMPTY*/
+ {
+ RPCommonSyntax *n = makeNode(RPCommonSyntax);
+ /* temporary set default to ST_NEXT_ROW */
+ n->rpSkipTo = ST_PAST_LAST_ROW;
+ n->rpSkipVariable = NULL;
+ $$ = n;
+ }
+ ;
+
+first_or_last:
+ FIRST_P { $$ = ST_FIRST_VARIABLE; }
+ | LAST_P { $$ = ST_LAST_VARIABLE; }
+ ;
+
+opt_row_pattern_initial_or_seek:
+ INITIAL { $$ = true; }
+ | SEEK
+ {
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("SEEK is not supported"),
+ errhint("Use INITIAL."),
+ parser_errposition(@1)));
+ }
+ | /*EMPTY*/ { $$ = true; }
+ ;
+
+row_pattern:
+ row_pattern_term { $$ = list_make1($1); }
+ | row_pattern row_pattern_term { $$ = lappend($1, $2); }
+ ;
+
+row_pattern_term:
+ ColId { $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "", (Node *)makeString($1), NULL, @1); }
+ | ColId '*' { $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "*", (Node *)makeString($1), NULL, @1); }
+ | ColId '+' { $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "+", (Node *)makeString($1), NULL, @1); }
+ | ColId '?' { $$ = (Node *) makeSimpleA_Expr(AEXPR_OP, "?", (Node *)makeString($1), NULL, @1); }
+ ;
+
+opt_row_pattern_subset_clause:
+ SUBSET row_pattern_subset_list { $$ = $2; }
+ | /*EMPTY*/ { $$ = NIL; }
+ ;
+
+row_pattern_subset_list:
+ row_pattern_subset_item { $$ = list_make1($1); }
+ | row_pattern_subset_list ',' row_pattern_subset_item { $$ = lappend($1, $3); }
+ | /*EMPTY*/ { $$ = NIL; }
+ ;
+
+row_pattern_subset_item: ColId '=' '(' row_pattern_subset_rhs ')'
+ {
+ RPSubsetItem *n = makeNode(RPSubsetItem);
+ n->name = $1;
+ n->rhsVariable = $4;
+ $$ = n;
+ }
+ ;
+
+row_pattern_subset_rhs:
+ ColId { $$ = list_make1(makeStringConst($1, @1)); }
+ | row_pattern_subset_rhs ',' ColId { $$ = lappend($1, makeStringConst($3, @1)); }
+ | /*EMPTY*/ { $$ = NIL; }
+ ;
+
+row_pattern_definition_list:
+ row_pattern_definition { $$ = list_make1($1); }
+ | row_pattern_definition_list ',' row_pattern_definition { $$ = lappend($1, $3); }
+ ;
+
+row_pattern_definition:
+ ColId AS a_expr
+ {
+ $$ = makeNode(ResTarget);
+ $$->name = $1;
+ $$->indirection = NIL;
+ $$->val = (Node *) $3;
+ $$->location = @1;
+ }
+ ;
/*
* Supporting nonterminals for expressions.
@@ -17190,6 +17368,7 @@ unreserved_keyword:
| INDEXES
| INHERIT
| INHERITS
+ | INITIAL
| INLINE_P
| INPUT_P
| INSENSITIVE
@@ -17217,6 +17396,7 @@ unreserved_keyword:
| MATCHED
| MATERIALIZED
| MAXVALUE
+ | MEASURES
| MERGE
| METHOD
| MINUTE_P
@@ -17259,6 +17439,9 @@ unreserved_keyword:
| PARTITION
| PASSING
| PASSWORD
+ | PAST
+ | PATTERN_P
+ | PERMUTE
| PLANS
| POLICY
| PRECEDING
@@ -17309,6 +17492,7 @@ unreserved_keyword:
| SEARCH
| SECOND_P
| SECURITY
+ | SEEK
| SEQUENCE
| SEQUENCES
| SERIALIZABLE
@@ -17334,6 +17518,7 @@ unreserved_keyword:
| STRICT_P
| STRIP_P
| SUBSCRIPTION
+ | SUBSET
| SUPPORT
| SYSID
| SYSTEM_P
@@ -17521,6 +17706,7 @@ reserved_keyword:
| CURRENT_USER
| DEFAULT
| DEFERRABLE
+ | DEFINE
| DESC
| DISTINCT
| DO
@@ -17683,6 +17869,7 @@ bare_label_keyword:
| DEFAULTS
| DEFERRABLE
| DEFERRED
+ | DEFINE
| DEFINER
| DELETE_P
| DELIMITER
@@ -17758,6 +17945,7 @@ bare_label_keyword:
| INDEXES
| INHERIT
| INHERITS
+ | INITIAL
| INITIALLY
| INLINE_P
| INNER_P
@@ -17807,6 +17995,7 @@ bare_label_keyword:
| MATCHED
| MATERIALIZED
| MAXVALUE
+ | MEASURES
| MERGE
| METHOD
| MINVALUE
@@ -17860,6 +18049,9 @@ bare_label_keyword:
| PARTITION
| PASSING
| PASSWORD
+ | PAST
+ | PATTERN_P
+ | PERMUTE
| PLACING
| PLANS
| POLICY
@@ -17916,6 +18108,7 @@ bare_label_keyword:
| SCROLL
| SEARCH
| SECURITY
+ | SEEK
| SELECT
| SEQUENCE
| SEQUENCES
@@ -17947,6 +18140,7 @@ bare_label_keyword:
| STRICT_P
| STRIP_P
| SUBSCRIPTION
+ | SUBSET
| SUBSTRING
| SUPPORT
| SYMMETRIC
diff --git a/src/include/nodes/parsenodes.h b/src/include/nodes/parsenodes.h
index e494309da8..094c603887 100644
--- a/src/include/nodes/parsenodes.h
+++ b/src/include/nodes/parsenodes.h
@@ -540,6 +540,44 @@ typedef struct SortBy
int location; /* operator location, or -1 if none/unknown */
} SortBy;
+/*
+ * AFTER MATCH row pattern skip to types in row pattern common syntax
+ */
+typedef enum RPSkipTo
+{
+ ST_NONE, /* AFTER MATCH omitted */
+ ST_NEXT_ROW, /* SKIP TO NEXT ROW */
+ ST_PAST_LAST_ROW, /* SKIP TO PAST LAST ROW */
+ ST_FIRST_VARIABLE, /* SKIP TO FIRST variable name */
+ ST_LAST_VARIABLE, /* SKIP TO LAST variable name */
+ ST_VARIABLE /* SKIP TO variable name */
+} RPSkipTo;
+
+/*
+ * Row Pattern SUBSET clause item
+ */
+typedef struct RPSubsetItem
+{
+ NodeTag type;
+ char *name; /* Row Pattern SUBSET clause variable name */
+ List *rhsVariable; /* Row Pattern SUBSET rhs variables (list of char *string) */
+} RPSubsetItem;
+
+/*
+ * RowPatternCommonSyntax - raw representation of row pattern common syntax
+ *
+ */
+typedef struct RPCommonSyntax
+{
+ NodeTag type;
+ RPSkipTo rpSkipTo; /* Row Pattern AFTER MATCH SKIP type */
+ char *rpSkipVariable; /* Row Pattern Skip To variable name, if any */
+ bool initial; /* true if <row pattern initial or seek> is initial */
+ List *rpPatterns; /* PATTERN variables (list of A_Expr) */
+ List *rpSubsetClause; /* row pattern subset clause (list of RPSubsetItem), if any */
+ List *rpDefs; /* row pattern definitions clause (list of ResTarget) */
+} RPCommonSyntax;
+
/*
* WindowDef - raw representation of WINDOW and OVER clauses
*
@@ -555,6 +593,8 @@ typedef struct WindowDef
char *refname; /* referenced window name, if any */
List *partitionClause; /* PARTITION BY expression list */
List *orderClause; /* ORDER BY (list of SortBy) */
+ List *rowPatternMeasures; /* row pattern measures (list of ResTarget) */
+ RPCommonSyntax *rpCommonSyntax; /* row pattern common syntax */
int frameOptions; /* frame_clause options, see below */
Node *startOffset; /* expression for starting bound, if any */
Node *endOffset; /* expression for ending bound, if any */
@@ -1476,6 +1516,11 @@ typedef struct GroupingSet
* the orderClause might or might not be copied (see copiedOrder); the framing
* options are never copied, per spec.
*
+ * "defineClause" is Row Pattern Recognition DEFINE clause (list of
+ * TargetEntry). TargetEntry.resname represents row pattern definition
+ * variable name. "patternVariable" and "patternRegexp" represents PATTERN
+ * clause.
+ *
* The information relevant for the query jumbling is the partition clause
* type and its bounds.
*/
@@ -1507,6 +1552,17 @@ typedef struct WindowClause
Index winref; /* ID referenced by window functions */
/* did we copy orderClause from refname? */
bool copiedOrder pg_node_attr(query_jumble_ignore);
+ /* Row Pattern AFTER MACH SKIP clause */
+ RPSkipTo rpSkipTo; /* Row Pattern Skip To type */
+ bool initial; /* true if <row pattern initial or seek> is initial */
+ /* Row Pattern DEFINE clause (list of TargetEntry) */
+ List *defineClause;
+ /* Row Pattern DEFINE variable initial names (list of String) */
+ List *defineInitial;
+ /* Row Pattern PATTERN variable name (list of String) */
+ List *patternVariable;
+ /* Row Pattern PATTERN regular expression quantifier ('+' or ''. list of String) */
+ List *patternRegexp;
} WindowClause;
/*
diff --git a/src/include/parser/kwlist.h b/src/include/parser/kwlist.h
index 5984dcfa4b..2804333b53 100644
--- a/src/include/parser/kwlist.h
+++ b/src/include/parser/kwlist.h
@@ -128,6 +128,7 @@ PG_KEYWORD("default", DEFAULT, RESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("defaults", DEFAULTS, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("deferrable", DEFERRABLE, RESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("deferred", DEFERRED, UNRESERVED_KEYWORD, BARE_LABEL)
+PG_KEYWORD("define", DEFINE, RESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("definer", DEFINER, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("delete", DELETE_P, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("delimiter", DELIMITER, UNRESERVED_KEYWORD, BARE_LABEL)
@@ -212,6 +213,7 @@ PG_KEYWORD("index", INDEX, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("indexes", INDEXES, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("inherit", INHERIT, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("inherits", INHERITS, UNRESERVED_KEYWORD, BARE_LABEL)
+PG_KEYWORD("initial", INITIAL, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("initially", INITIALLY, RESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("inline", INLINE_P, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("inner", INNER_P, TYPE_FUNC_NAME_KEYWORD, BARE_LABEL)
@@ -265,6 +267,7 @@ PG_KEYWORD("match", MATCH, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("matched", MATCHED, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("materialized", MATERIALIZED, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("maxvalue", MAXVALUE, UNRESERVED_KEYWORD, BARE_LABEL)
+PG_KEYWORD("measures", MEASURES, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("merge", MERGE, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("method", METHOD, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("minute", MINUTE_P, UNRESERVED_KEYWORD, AS_LABEL)
@@ -326,6 +329,9 @@ PG_KEYWORD("partial", PARTIAL, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("partition", PARTITION, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("passing", PASSING, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("password", PASSWORD, UNRESERVED_KEYWORD, BARE_LABEL)
+PG_KEYWORD("past", PAST, UNRESERVED_KEYWORD, BARE_LABEL)
+PG_KEYWORD("pattern", PATTERN_P, UNRESERVED_KEYWORD, BARE_LABEL)
+PG_KEYWORD("permute", PERMUTE, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("placing", PLACING, RESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("plans", PLANS, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("policy", POLICY, UNRESERVED_KEYWORD, BARE_LABEL)
@@ -385,6 +391,7 @@ PG_KEYWORD("scroll", SCROLL, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("search", SEARCH, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("second", SECOND_P, UNRESERVED_KEYWORD, AS_LABEL)
PG_KEYWORD("security", SECURITY, UNRESERVED_KEYWORD, BARE_LABEL)
+PG_KEYWORD("seek", SEEK, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("select", SELECT, RESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("sequence", SEQUENCE, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("sequences", SEQUENCES, UNRESERVED_KEYWORD, BARE_LABEL)
@@ -416,6 +423,7 @@ PG_KEYWORD("stored", STORED, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("strict", STRICT_P, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("strip", STRIP_P, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("subscription", SUBSCRIPTION, UNRESERVED_KEYWORD, BARE_LABEL)
+PG_KEYWORD("subset", SUBSET, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("substring", SUBSTRING, COL_NAME_KEYWORD, BARE_LABEL)
PG_KEYWORD("support", SUPPORT, UNRESERVED_KEYWORD, BARE_LABEL)
PG_KEYWORD("symmetric", SYMMETRIC, RESERVED_KEYWORD, BARE_LABEL)
diff --git a/src/include/parser/parse_node.h b/src/include/parser/parse_node.h
index f589112d5e..6640090910 100644
--- a/src/include/parser/parse_node.h
+++ b/src/include/parser/parse_node.h
@@ -51,6 +51,7 @@ typedef enum ParseExprKind
EXPR_KIND_WINDOW_FRAME_RANGE, /* window frame clause with RANGE */
EXPR_KIND_WINDOW_FRAME_ROWS, /* window frame clause with ROWS */
EXPR_KIND_WINDOW_FRAME_GROUPS, /* window frame clause with GROUPS */
+ EXPR_KIND_RPR_DEFINE, /* DEFINE */
EXPR_KIND_SELECT_TARGET, /* SELECT target list item */
EXPR_KIND_INSERT_TARGET, /* INSERT target list item */
EXPR_KIND_UPDATE_SOURCE, /* UPDATE assignment source item */
--
2.25.1
----Next_Part(Wed_Nov__8_16_37_05_2023_872)--
Content-Type: Text/X-Patch; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="v11-0002-Row-pattern-recognition-patch-parse-analysis.patch"
^ permalink raw reply [nested|flat] 15+ messages in thread
end of thread, other threads:[~2023-11-08 06:57 UTC | newest]
Thread overview: 15+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-01-13 11:05 [PATCH v3 1/2] Fix ALTER PUBLICATION...DROP TABLE behaviour Bharath Rupireddy <[email protected]>
2022-10-15 21:19 macos ventura SDK spews warnings Andres Freund <[email protected]>
2022-10-15 21:56 ` Re: macos ventura SDK spews warnings Tom Lane <[email protected]>
2022-10-15 22:47 ` Re: macos ventura SDK spews warnings Tom Lane <[email protected]>
2022-10-15 23:50 ` Re: macos ventura SDK spews warnings Andres Freund <[email protected]>
2022-10-16 00:08 ` Re: macos ventura SDK spews warnings Tom Lane <[email protected]>
2022-10-16 01:00 ` Re: macos ventura SDK spews warnings Tom Lane <[email protected]>
2022-10-16 05:34 ` Re: macos ventura SDK spews warnings Andres Freund <[email protected]>
2022-10-16 16:40 ` Re: macos ventura SDK spews warnings Tom Lane <[email protected]>
2022-10-16 17:35 ` Re: macos ventura SDK spews warnings Tom Lane <[email protected]>
2022-10-16 20:45 ` Re: macos ventura SDK spews warnings Tom Lane <[email protected]>
2022-10-16 21:59 ` Re: macos ventura SDK spews warnings Andres Freund <[email protected]>
2022-10-16 22:29 ` Re: macos ventura SDK spews warnings Tom Lane <[email protected]>
2022-10-16 00:14 ` Re: macos ventura SDK spews warnings Andres Freund <[email protected]>
2023-11-08 06:57 [PATCH v11 1/7] Row pattern recognition patch for raw parser. Tatsuo Ishii <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox