mirror of
https://github.com/postgres/postgres.git
synced 2025-11-24 00:23:06 +03:00
de3600452b
JSON_TABLE() allows JSON data to be converted into a relational view
and thus used, for example, in a FROM clause, like other tabular
data. Data to show in the view is selected from a source JSON object
using a JSON path expression to get a sequence of JSON objects that's
called a "row pattern", which becomes the source to compute the
SQL/JSON values that populate the view's output columns. Column
values themselves are computed using JSON path expressions applied to
each of the JSON objects comprising the "row pattern", for which the
SQL/JSON query functions added in 6185c9737c are used.
To implement JSON_TABLE() as a table function, this augments the
TableFunc and TableFuncScanState nodes that are currently used to
support XMLTABLE() with some JSON_TABLE()-specific fields.
Note that the JSON_TABLE() spec includes NESTED COLUMNS and PLAN
clauses, which are required to provide more flexibility to extract
data out of nested JSON objects, but they are not implemented here
to keep this commit of manageable size.
Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Andrew Dunstan <andrew@dunslane.net>
Author: Amit Langote <amitlangote09@gmail.com>
Author: Jian He <jian.universality@gmail.com>
Reviewers have included (in no particular order):
Andres Freund, Alexander Korotkov, Pavel Stehule, Andrew Alsup,
Erik Rijkers, Zihong Yu, Himanshu Upadhyaya, Daniel Gustafsson,
Justin Pryzby, Álvaro Herrera, Jian He
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
Discussion: https://postgr.es/m/CA+HiwqE4XTdfb1nW=Ojoy_tQSRhYt-q_kb6i5d4xcKyrLC1Nbg@mail.gmail.com
73 lines
1.8 KiB
Makefile
73 lines
1.8 KiB
Makefile
#-------------------------------------------------------------------------
|
|
#
|
|
# Makefile for parser
|
|
#
|
|
# src/backend/parser/Makefile
|
|
#
|
|
#-------------------------------------------------------------------------
|
|
|
|
subdir = src/backend/parser
|
|
top_builddir = ../../..
|
|
include $(top_builddir)/src/Makefile.global
|
|
|
|
override CPPFLAGS := -I. -I$(srcdir) $(CPPFLAGS)
|
|
|
|
OBJS = \
|
|
analyze.o \
|
|
gram.o \
|
|
parse_agg.o \
|
|
parse_clause.o \
|
|
parse_coerce.o \
|
|
parse_collate.o \
|
|
parse_cte.o \
|
|
parse_enr.o \
|
|
parse_expr.o \
|
|
parse_func.o \
|
|
parse_jsontable.o \
|
|
parse_merge.o \
|
|
parse_node.o \
|
|
parse_oper.o \
|
|
parse_param.o \
|
|
parse_relation.o \
|
|
parse_target.o \
|
|
parse_type.o \
|
|
parse_utilcmd.o \
|
|
parser.o \
|
|
scan.o \
|
|
scansup.o
|
|
|
|
include $(top_srcdir)/src/backend/common.mk
|
|
|
|
|
|
# There is no correct way to write a rule that generates two files.
|
|
# Rules with two targets don't have that meaning, they are merely
|
|
# shorthand for two otherwise separate rules. If we have an action
|
|
# that in fact generates two or more files, we must choose one of them
|
|
# as primary and show it as the action's output, then make all of the
|
|
# other output files dependent on the primary, like this. Furthermore,
|
|
# the "touch" action is essential, because it ensures that gram.h is
|
|
# marked as newer than (or at least no older than) gram.c. Without that,
|
|
# make is likely to try to rebuild gram.h in subsequent runs, which causes
|
|
# failures in VPATH builds from tarballs.
|
|
|
|
gram.h: gram.c
|
|
touch $@
|
|
|
|
gram.c: BISONFLAGS += -d
|
|
gram.c: BISON_CHECK_CMD = $(PERL) $(srcdir)/check_keywords.pl $< $(top_srcdir)/src/include/parser/kwlist.h
|
|
|
|
|
|
scan.c: FLEXFLAGS = -CF -p -p
|
|
scan.c: FLEX_NO_BACKUP=yes
|
|
scan.c: FLEX_FIX_WARNING=yes
|
|
|
|
|
|
# Force these dependencies to be known even without dependency info built:
|
|
gram.o scan.o parser.o: gram.h
|
|
|
|
clean:
|
|
rm -f gram.c \
|
|
gram.h \
|
|
scan.c
|
|
rm -f lex.backup
|