On 06/02/25 14:13, Tom Lane wrote:
> Here's a proposed patch for the "=" issue. Whether or not we should
> rethink FDW validation behavior, doing so surely couldn't be
> back-patched. But I think this much should be.
LGTM
Regards,
-Chap
On 05/31/25 21:12, Tom Lane wrote:
> I think you're overthinking it. There is one round of dequoting
> and downcasing in the grammar, and after that a name is just a
> literal string. It's perfectly okay to just store that string and
> do exact comparisons to it against other names (which themsel
On 05/31/25 19:55, Tom Lane wrote:
> Chapman Flack writes:
>> SQL rules would also make its case-sensitivity dependent on faithfully
>> recovering whether it was delimited or not.
>
> I'm not following that part?
It's that ISO rule that identifiers match cas
On 05/27/25 09:29, Laurenz Albe wrote:
> There is no "supported". Each extension has to support itself.
> An exception are the "contrib" extensions shipped with PostgreSQL:
> they are supported by the PGDG.
>
> There is also no complete list of extensions that I am aware of.
There is some info i
Hi,
generic_option_name is a ColLabel, therefore a fully general SQL identifier.
But a command like CREATE FOREIGN DATA WRAPPER w ... OPTIONS ("a=b" 'c=d')
stores {a=b=c=d} in fdwoptions, from which the original intent can't be
recovered.
Should generic_option_name be restricted to be a regular
On 04/19/25 19:32, Chapman Flack wrote:
> On 04/19/25 19:12, Tom Lane wrote:
>> You could argue that
>> CREATE FUNCTION foo(anyelement) RETURNS anyelement
>> TRANSFORM FOR TYPE int
>> AS ...;
>> should mean that if the actual argument type is int, then the
>>
On 04/19/25 19:12, Tom Lane wrote:
> You could argue that
> CREATE FUNCTION foo(anyelement) RETURNS anyelement
> TRANSFORM FOR TYPE int
> AS ...;
> should mean that if the actual argument type is int, then the
> mentioned transform should be applied to the input and result;
> but if it's some other
On 04/19/25 15:03, Tom Lane wrote:
> So what are the odds that outside PLs do it correctly (for whatever
> you think "correctly" is)? It doesn't help any that we document
> none of this.
My sense of Déjà vu turns out to be because I had a bunch of proposed
new documentation and example code for p
Also noticing about transforms:
1. protrftypes can have duplicates.
In part, this is because CreateFunction does nothing to stop you saying
redundant things like TRANSFORM FOR TYPE circle, FOR TYPE circle.
But it is also because:
2. CreateFunction hands every type seen in TRANSFORM FOR
On 04/15/25 23:39, Tom Lane wrote:
> My own beef with the whole setup is that you can't specify *which*
> arguments or results you want transformed. I don't believe that
> this should have been keyed off data types to begin with. But
> that design was the SQL committee's choice so we're stuck ...
On 04/15/25 10:52, Tom Lane wrote:
> The problem from a PL's standpoint is "given this input or output
> of type FOO, should I transform it, and if so using what?". So
> the starting point has to be a type not a transform. ... protrftypes data
> is used as a filter before attempting a pg_transform
On 04/06/25 22:37, Tom Lane wrote:
> Here's a draft patch to fix the bogus dependencies. As given this'd
> only be okay for HEAD, since I doubt we can get away with changing
> ProcedureCreate()'s signature in stable branches ... In the back branches
> we could make ProcedureCreate() deconstruct th
On 04/09/25 10:03, Tom Lane wrote:
> I think I stole it from DB2:
>
> 10608 An error was encountered in the argument of an XQuery function or
> operator.
Interesting. ISO does seem to reserve a class 10 for XQuery errors, but
not to define any subclass codes within it.
Every other SQL/XML error
On 04/06/25 13:59, Tom Lane wrote:
> polymorphic arguments: the element type of an anyarray argument can
> change on-the-fly from one call to the next in the same query. I
> think this is only possible when you're fed pg_stats.most_common_vals
> or one of its sibling columns, but that's enough to
On 04/06/25 20:01, Tom Lane wrote:
> Looking more closely at ProcedureCreate(), it makes a dependency
> if a transform *exists* for the argument or result type, whether
> a TRANSFORM clause is present or not. Surely this is completely
> bogus? We should be depending on the OIDs mentioned in protr
On 04/06/25 15:47, Tom Lane wrote:
> Chapman Flack writes:
>> Can a spread-out variadic "any" arg list ever vary
>> in length or type on the fly at a single call site?
>
> Don't think so.
Only slightly tangentially: what things count as "objects that
On 04/06/25 13:33, Tom Lane wrote:
> Maybe you'd be interested in using funccache.
O funccache, where were you a year or two ago?
Can a spread-out variadic "any" arg list ever vary
in length or type on the fly at a single call site?
I notice that funccache only hashes the first nargs
argument typ
On 04/06/25 13:59, Tom Lane wrote:
> polymorphic arguments: the element type of an anyarray argument can
> change on-the-fly from one call to the next in the same query.
Yuck! I had not guessed that.
Regards,
-Chap
Hi hackers,
The way the core code allocates FmgrInfo structures has a pleasing property
(at least in the parts of the code I have read and the cases I've tested)
that the docs don't seem to emphasize.
To wit, given a query like
SELECT hello(n), hello(x)
FROM (VALUES
(1::int4, 1.0::float4),
(
Hi,
If a maintainer of a 20-year-old PL that never supported non-atomic
operation wants to catch up, it is easy enough to find the documentation
on SPI_connect_ext and SPI_OPT_NONATOMIC, and learn how to determine
the atomic/non-atomic state on entry from the atomic field of
InlineCodeBlock for a
On 02/06/25 16:06, Chris Cleveland wrote:
> I solved the problem with:
>
> CREATE FUNCTION myfunc ... RETURNS Token[] ... SET search_path to rdb;
>
> I still don't know why it happens in the first place, though.
That pretty much nails down that the type name appears somewhere
in the quoted-liter
Hi,
On 02/06/25 11:46, Chris Cleveland wrote:
> I'm developing a Postgres extension that gets installed in its own schema,
> "rdb". It creates its own type, "token", and has a function that returns an
> array of that type. When I SELECT the function in psql, I get an ERROR:
> type "token" does not
On 01/28/25 03:14, Jim Jones wrote:
> I'd say the difference is due to how the two systems handle the XML data
> type and unquoted identifiers in general, rather than a difference in
> the behaviour of the function itself.
I'd go further and say it's entirely down to how the two systems
handle un
On 01/25/25 02:16, Pavel Stehule wrote:
> because the function does nothing, then it is useless to convert input to
> XML and force detosting
>
> Maybe the body of the function should be just
> ...
> PG_RETURN_DATUM(PG_GETARG_DATUM(0));
That sort of motivated my question upthread about whether
On 01/24/25 14:59, Jim Jones wrote:
> In the XML Query standard, a "document node" represents a relaxed
> version of an XML document structure. This corresponds to what
> PostgreSQL's single XML type allows, meaning that any valid non-null
> PostgreSQL XML value can be returned unchanged. Other sys
On 01/24/25 10:49, Chapman Flack wrote:
> The SQL-standard `XMLDOCUMENT` function applied to an XML value
> /expr/ has effects equivalent to the XML Query expression
> `document { /expr/ }`, specified to replace any document nodes
> in the input with their children and wrap the whole r
On 01/24/25 08:48, Jim Jones wrote:
> In the SQL/XML specification, the XMLDocument (X030) function is
> designed to return a document node from a given XML value expression.
Maybe we can take advantage of the way that specifications usually
don't mandate an implementation, but only results equiva
On 01/22/25 13:41, Robert Treat wrote:
> So even if we are following the spec (which I think technically we may
> not be),
There are definite ways in which we're not following the SQL/XML spec,
which we document in an appendix[1]. The one that matters here is that
we just have a single XML type in
On 01/19/25 12:02, Tom Lane wrote:
> You can build that yourself, typically by adding a trigger that stores
> the value of "current_user" into inserted/updated rows. (If you want
> to also track deletions, a separate audit log table would work
> better.) The event-trigger feature might also be us
On 01/20/25 14:56, Jim Jones wrote:
> If I understand correctly, the compliant approach would be to always
> treat the input expression as CONTENT:
>
> |PG_RETURN_XML_P(xmlparse((text *) data, XMLOPTION_DOCUMENT, true));|
>
> Is that right?"
Did you mean XMLOPTION_CONTENT?
I think that would be
On 01/20/25 06:02, Jim Jones wrote:
> The DB2 "Document node constructors" might provide some insights into
> its behavior regarding well-formed XML documents [1]:
>
> "No validation is performed on the constructed document node. The XQuery
> document node constructor does not enforce the XML 1.0
On 12/23/24 17:26, David E. Wheeler wrote:
> On Dec 23, 2024, at 15:17, Tom Lane wrote:
>> How would that work for extensions where the C code is intentionally
>> supporting multiple versions of the SQL objects?
>
> I guess some people do that, eh? In that case it wouldn’t.
A function pointer ra
On 10/11/24 01:33, Steve Lau wrote:
> Before hitting the issue, I thought -1 will be passed if and only if
> this type does not have type modifiers, as it is indeed unknown. However,
> it surprises me that it could also be unknown if your type needs
> type modifiers and the type modifiers have been
On 09/09/24 13:00, Robert Haas wrote:
> I don't agree with this reponse at all. It seems entirely reasonable
> for third-party code to want to have a way to construct and interpret
> numeric datums. Keeping the details private would MAYBE make sense if
> the internal details were changing release t
On 07/27/24 00:32, Tom Lane wrote:
> Interval typmods include a fractional-seconds-precision field as well
> as a bitmask indicating the allowed interval fields (per the SQL
> standard's weird syntax such as INTERVAL DAY TO SECOND). Looking at
> the source code for intervaltypmodout() might be hel
On 07/15/24 10:46, Chapman Flack wrote:
> Ah, I may have mistaken which functions the patch meant to apply to.
> ...
> Any choice to use similar argument names in the regexp_* functions would
> be a matter of consistency with the analogous ISO functions, not anything
> mandated.
O
On 07/15/24 08:02, jian he wrote:
> also address Chapman Flack point:
> correct me if i am wrong, but i don't think the ISO standard mandates
> function argument names.
> So we can choose the best function argument name for our purpose?
Ah, I may have mistaken which functions t
On 06/20/24 10:54, David E. Wheeler wrote:
> Still not sure about `24:00:00` as a time, though. I presume the jsonpath
> standard disallows it.
In 9075-2 9.46 "SQL/JSON path language: syntax and semantics", the behavior
of the .time() and .time_tz() and similar item methods defers to the
behavior
On 06/18/24 08:30, Peter Eisentraut wrote:
> Are you saying we shouldn't allow .boolean() to be called on a JSON number?
>
> I would concur that that's what the spec says.
Or, if we want to extend the spec and allow .boolean() on a JSON number,
should it just check that the number is nonzero or z
On 06/17/24 19:17, David E. Wheeler wrote:
> [1]:
> https://github.com/postgres/postgres/blob/82ed67a/src/backend/utils/adt/jsonpath_exec.c#L2058-L2059
Huh, I just saw something peculiar, skimming through the code:
https://github.com/postgres/postgres/blob/82ed67a/src/backend/utils/adt/jsonpath_
On 06/17/24 18:14, David E. Wheeler wrote:
> So I think that’s the key: There’s not a difference between the behavior of
> `like_regex` and `starts with` vs other predicate expressions.
The current implementation seems to have made each of our
s responsible for swallowing its own errors, which
is
Hi,
On 06/17/24 02:43, Amit Langote wrote:
> context_item expression can be a value of
> any type that can be cast to jsonb. This includes types
> such as char, text, bpchar,
> character varying, and bytea (with
> ENCODING UTF8), as well as any domains over these types.
Reading this message in c
Hi,
On 06/17/24 02:20, Amit Langote wrote:
>>>Apparently, the functions expect JSONB so that a cast is implied
>>>when providing TEXT. However, the errors during that cast are
>>>not subject to the ON ERROR clause.
>>>
>>>17beta1=# SELECT JSON_QUERY('invalid', '$' NULL ON ERROR);
>
On 06/15/24 10:47, David E. Wheeler wrote:
> these are predicate check expressions, supported and documented
> as an extension to the standard since Postgres 12[1].
> ...
> [1]:
> https://www.postgresql.org/docs/devel/functions-json.html#FUNCTIONS-SQLJSON-CHECK-EXPRESSIONS
I see. Yes, that docume
On 06/14/24 22:29, Chapman Flack wrote:
> So I should go look at our code to see what grammar we've implemented,
> exactly. It is beginning to seem as if we have simply added
> as another choice for an expression, not restricted
> to only appearing in a filter. If so, and we
egin with, both of those path queries should have been rejected at
the parsing stage, just like the one David Johnson pointed out:
On 06/13/24 22:14, David G. Johnston wrote:
> On Thursday, June 13, 2024, Chapman Flack wrote:
>> On 06/13/24 21:46, David G. Johnston wrote:
>>>>>
On 06/14/24 10:39, David E. Wheeler wrote:
> Cited that bit in the commit message in the attached patch (also available as
> a GitHub PR[1]).
>
> [1]: https://github.com/theory/postgres/pull/5
I would s/extepsions/exceptions/ in the added documentation. :)
Offhand (as GitHub PRs aren't really T
On 06/13/24 22:16, David E. Wheeler wrote:
> But even inside filters I don’t understand why &&, ||, at least,
> currently only work if their operands are predicate expressions.
> Seems weird; and your notes above suggest that rule applies only to !,
> which makes slightly more sense.
It's baked ri
On 06/13/24 21:46, David G. Johnston wrote:
>>> david=# select jsonb_path_query('1', '$ >= 1');
>>
>> Good point. I can't either. No way I can see to parse that as
>> a .
>
> Whether we note it as non-standard or not is an open question then, but it
> does work and opens up a documentation questio
On 06/13/24 18:45, David E. Wheeler wrote:
> On Jun 13, 2024, at 3:53 PM, Andrew Dunstan wrote:
>
>> Hmm. You might be right. Many of these items have this code, but the
>> string() branch does not:
>> if (unwrap && JsonbType(jb) == jbvArray)
>>return executeItemUnwrapTargetArray(cxt, jsp, j
On 06/13/24 21:24, David G. Johnston wrote:
> I'm content that the operators in the 'filter operators' table need to be
> within filter but then I cannot reconcile why this example worked:
>
> david=# select jsonb_path_query('1', '$ >= 1');
Good point. I can't either. No way I can see to parse th
On 06/13/24 16:43, David E. Wheeler wrote:
> Paging Mr. Eisentraut!
I'm not Mr. Eisentraut, but I have at last talked my way into some
access to the standard, so ...
Note 487 emphasizes that JSON path predicates "are not expressions;
instead they form a separate language that can only be invoked
On 05/20/24 11:39, Tomas Vondra wrote:
> On 5/20/24 16:37, Sushrut Shivaswamy wrote:
>> I've tried various types and none of them read the correct value.
>> ```
>> ...
>> double current_time = DatumGetFloat8(current_timestamp); // prints 0
>>
>> int64 time = DatumGetUint64(current_timestamp); // pr
On 05/15/24 15:31, Robert Haas wrote:
> On Wed, May 15, 2024 at 3:23 PM Chapman Flack wrote:
>> What would be wrong with [occurrence], for consistency's sake?
>
> It was proposed and rejected upthread, but that's not to say that I
> necessarily endorse the reaso
On 05/15/24 15:07, Robert Haas wrote:
> is. I believe that if I were reading the documentation, count would be
> clearer to me than N, N would probably still be clear enough, and
> replace_at wouldn't be clear at all. I'd expect replace_at to be a
> character position or something, not an occurrenc
On 05/15/24 13:45, Tom Lane wrote:
> if we tell people to write
>
>PG_MODULE_MAGIC;
>#undef TEXTDOMAIN
>#define TEXTDOMAIN PG_TEXTDOMAIN("hstore")
>
> then that's 100% backwards compatible and they don't need any
> version-testing ifdef's.
OT for this thread, but related: supposing o
On 05/15/24 11:50, Tom Lane wrote:
> Hmm, cute idea, but it'd only help for extensions that are
> NLS-enabled. Which I bet is a tiny fraction of the population.
> So far as I can find, we don't even document how to set up
> TEXTDOMAIN for an extension --- you have to cargo-cult the
But I'd bet, w
On 05/13/24 09:35, aa wrote:
> If you call the action of "sifting" ordering, then yes. If you don't call
> it ordering, then no.
One thing seems intriguing about this idea: normally, an expected
property of any ORDER BY is that no result row can be passed down
the pipe until all input rows have b
Hi hackers,
More or less by chance, I stumbled on a Security Technical Implementation
Guide (STIG, promulgated by the US Dept. of Defense, Defense Information
Systems Agency) for PostgreSQL (specific to PG 9.x, so a bit dated).
There is a rule in the STIG that pertains to PLs, and seems to get
ba
Hi Rahul,
On 03/18/24 15:52, Rahul Uniyal wrote:
> Since the column format is text and not binary it converts the value
> to BigDecimal and give back the value as 40 .
> ...
> Now since the format is Binary ... it returns DOUBLE from there
> result in 40.0
>
> Now i am not sure for the same tabl
list.
Regards,
Chapman Flack
Adding this comment via the CF app so it isn't lost, while an
improperly-interpreted-DKIM-headers issue is still preventing me from mailing
directly to -hackers.
It was my view that the patch was getting close by the end of the last
commitfest, but still contained a bit of a logic wart made nec
On 2023-10-04 16:38, Jeff Davis wrote:
On Wed, 2023-10-04 at 14:02 -0400, Chapman Flack wrote:
The SQL standard would have me able to:
CREATE TABLE foo (
a CHARACTER VARYING CHARACTER SET UTF8,
b CHARACTER VARYING CHARACTER SET LATIN1
)
and so on
Is there a use case for that? UTF-8 is
On 2023-10-04 12:19, Jim Jones wrote:
On 04.10.23 11:39, vignesh C wrote:
1) Why the default option was chosen without comments shouldn't it be
the other way round?
I'm not sure it is the way to go. The main idea is to check if two
documents have the same content, and comments might be differen
On 2023-10-04 13:47, Robert Haas wrote:
On Wed, Oct 4, 2023 at 1:27 PM Nico Williams
wrote:
A UTEXT type would be helpful for specifying that the text must be
Unicode (in which transform?) even if the character data encoding for
the database is not UTF-8.
That's actually pretty thorny ... bec
On 2023-09-21 20:38, Andy Fan wrote:
insert into tb select '{"a": "foo", "b": 1}';
...
select cast(a->'a' as numeric) from tb;
ERRCODE_INVALID_PARAMETER_VALUE cannot cast jsonb string to type
numeric
...
select cast(a->'b' as int2) from tb;
NUMERIC_VALUE_OUT_OF_RANGE smallint out of ra
Hi,
This came up in [0] and opinions besides my own would be welcome.
There is a function cannotCastJsonbValue in jsonb.c, and it throws
errors
of this form:
ERRCODE_INVALID_PARAMETER_VALUE "cannot cast jsonb %1$s to type %2$s"
where %1 is one of the possible JsonbValue types (null, string,
On 2023-09-17 21:58, David G. Johnston wrote:
ambiguity possible when doing that though:
create type "interval second" as (x int, y int);
select to_regtype('interval second'); --> interval
Not ambiguity really: that composite type you just made was named
with a single , which is one token. (Al
On 2023-09-17 20:58, David G. Johnston wrote:
Put differently, there is no syntax involved when the value being
provided
is the text literal name of a type as it is stored in pg_type.typname,
so
the presence of a syntax error is wrong.
Well, the situation is a little weirder than that, becaus
Hi,
At one time 12 years ago, fn_collation was stored in FmgrInfo,
with a comment saying it was really "parse-time-determined
information about the arguments, rather than about the function
itself" but saying "it's convenient" to store it in FmgrInfo
rather than in FunctionCallInfoData.
But in d
On 2023-09-04 10:35, Andy Fan wrote:
v13 attached. Changes includes:
1. fix the bug Jian provides.
2. reduce more code duplication without DirectFunctionCall.
3. add the overlooked jsonb_path_query and jsonb_path_query_first as
candidates
Apologies for the delay. I like the way this is
On 2023-09-11 12:28, jacktby jacktby wrote:
2023年9月11日 23:51，Aleksander Alekseev 写道：
often better) add a corresponding extension to /contrib/. You can find
a complete example here [1] for instance, see v4-0001 patch and the
function pg_get_relation_publishing_info(). Make sure it has a proper
vo
On 2023-09-01 09:25, John Naylor wrote:
On Fri, Sep 1, 2023 at 7:48 PM Jelte Fennema
wrote:
The C standard says:
> When a value is stored in an object of structure or union type,
> including in a member object, the bytes of the object representation that
> correspond to any padding bytes take u
On 2023-08-31 20:50, Vik Fearing wrote:
— An SQL/JSON item is defined recursively as any of the following:
...
• An SQL/JSON array, defined as an ordered list of zero or more
SQL/JSON items, called the SQL/JSON elements of the SQL/JSON
array.
...
— An SQL/JSON sequence is an o
On 2023-08-30 12:28, Alvaro Herrera wrote:
Yeah, I think the experience of the SQL committee with XML was pretty
bad, as you carefully documented. I hope they don't make such a mess
with JSON.
I guess the SQL committee was taken by surprise after basing something
on Infoset and XPath 1.0 for 2
On 2023-08-30 11:18, Chapman Flack wrote:
If I look in [1], am I looking in the right place for the most
current jsonpath draft?
My bad, I see that it is not. Um if I look in [1'], am I then looking
at the same spec you are?
[1'] https://www.ietf.org/archive/id/draft-ietf-jsonpa
Hi,
On 2023-08-29 03:05, Jeevan Chalke wrote:
This commit implements jsonpath .bigint(), .integer(), and .number()
---
This commit implements jsonpath .date(), .time(), .time_tz(),
.timestamp(), .timestamp_tz() methods.
---
This commit implements jsonpath .boolean() and .string() methods.
Writ
On 2023-08-30 00:47, Andy Fan wrote:
see what it is. Suppose the original query is:
numeric(jsonb_object_field(v_jsonb, text)) -> numeric.
...
However the declared type of jsonb_object_field_type is:
jsonb_object_field_type(internal, jsonb, text) -> internal.
So the situation is: b). We retu
Hi,
Although this is a ten-year-old message, it was the one I found quickly
when looking to see what the current state of play on this might be.
On 2013-09-20 14:22, Robert Haas wrote:
Hmm. So under that design, a database could support up to a total of
two character sets, the one that you get
On 2023-08-22 08:16, Chapman Flack wrote:
On 2023-08-22 01:54, Andy Fan wrote:
After we label it, we will get error like this:
select (a->'a')::int4 from m;
ERROR: cannot display a value of type internal
Without looking in depth right now, I would double-check
what relabel
On 2023-08-26 16:00, Pavel Stehule wrote:
Saxon can be an interesting library, but nobody knows if integration
with
Postgres is possible. Their C implementation is Java compiled/executed
by GraalV.
Indeed, such an integration would probably not be in core.
Of the two possible-ways-forward des
On 2023-08-26 13:02, Alvaro Herrera wrote:
Sadly, all the projects seem to have been pretty much abandoned in the
meantime. Zorba has been dead for 9 years, xqilla for 6. Even XQC,
the
API they claim to implement, is dead.
Sounds like bad news for the "XQC as integration point" proposal,
a
On 2023-08-25 10:49, Vik Fearing wrote:
I do not think this should be addressed in this patch because
there are quite a lot of functions that need to handle this.
Indeed, as described in [0], we still largely provide the SQL/XML:2003
notion of a single XML datatype, not the distinguishable XML(
On 2023-08-24 11:23, Jonathan S. Katz wrote:
SELECT $1::int + $2::int \bind 1 2 \g
One cast also works, letting type inference figure out the other.
So if I say
SELECT $1::int + $2 \gdesc
it tells me the result will be int. That made me wonder if there is
a \gdesc variant to issue the "state
On 2023-08-24 10:07, Maxim Orlov wrote:
1) Why do I need to specify the number of elements in the list in the
function name?
This is reminding me of something someone (Tom?) worked on sort of
recently.
Ah, yes:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=1cff1b9
I wasn't
On 2023-08-22 01:54, Andy Fan wrote:
After we label it, we will get error like this:
select (a->'a')::int4 from m;
ERROR: cannot display a value of type internal
Without looking in depth right now, I would double-check
what relabel node is being applied at the result. The idea,
of course, was
On 2023-08-20 21:31, Andy Fan wrote:
Highlighting the user case of makeRelableType is interesting! But using
the Oid directly looks more promising for this question IMO, it looks
like:
"you said we can put anything in this arg, so I put an OID const
here",
seems nothing is wrong.
Perhaps on
Hi,
Thread [1] concerns (generalizing slightly) the efficient casting
to an SQL type of the result of a jsonb extracting operation
(array indexing, object keying, path evaluation) that has ended
with a scalar JsonbValue.
So far, it can efficiently rewrite casts to boolean or numeric
types.
I no
On 2023-08-18 15:08, Chapman Flack wrote:
But I don't know that adding relabel nodes wouldn't still be
the civilized thing to do.
Interestingly, when I relabel both places, like this:
Oid targetOid = fexpr->funcresulttype;
Const *target = makeConst(
OIDOID, -
On 2023-08-18 14:50, Chapman Flack wrote:
Now, my guess is EXPLAIN is complaining when it sees the Const
of type internal, and doesn't know how to show that value.
Perhaps makeRelabelType is the answer there, too: what if the
Const has Oid type, so EXPLAIN can show it, and what's inser
On 2023-08-18 03:41, Andy Fan wrote:
I just have
a quick hack on this, and crash happens at the simplest case.
If I build from this patch, this test:
SELECT (test_json -> 0)::int4, test_json -> 0 FROM test_jsonb WHERE
json_type = 'scalarint';
fails like this:
Program received signal SIGSEG
On 2023-08-17 21:14, Andy Fan wrote:
The idea of an 'internal' return type with no 'internal' parameter
was quickly and rightly shot down.
Yes, it mainly breaks the type-safety system. Parser need to know
the result type, so PG defines the rule like this:
Well, the reason "internal return ty
On 2023-08-17 05:07, Andy Fan wrote:
Thanks for the review, v9 attached!
From the earliest iterations of this patch, I seem to recall
a couple of designs being considered:
In one, the type-specific cast function would only be internally
usable, would take a type oid as an extra parameter (sup
On 2023-08-14 03:06, Andy Fan wrote:
We'd still have functions like jsonb_field_as_numeric() under the
hood, but there's not an expectation that users call them explicitly.
To avoid the lots of functions like jsonb_field_as_int2/int4, I defined
Datum jsonb_object_field_type(.., Oid target_oid)
On 2023-08-14 09:11, Erik Rijkers wrote:
, '$' returning date[]
I certainly like that syntax better.
It's not that the "here's a null to tell you the type I want"
is terribly unclear, but it seems not to be an idiom I have
seen a lot of in PostgreSQL before now. Are there other places
it's c
Hi,
Looking at the most recent patch, so far I have a minor
spelling point, and a question (which I have not personally
explored).
The minor spelling point, the word 'field' has been spelled
'filed' throughout this comment (just as in the email subject):
+ /*
+* Si
On 2023-08-03 23:55, Andy Fan wrote:
> The double quotes look weird to me. but it looks like a common
> situation.
>
> select numeric('1'::int); -- failed.
> select "numeric"('1'::int); -- ok.
It arises when you have an object (type, function, cast, whatever) whose
name in the catalog is the sa
On 2023-08-03 03:53, Andy Fan wrote:
I didn't realize timetime types are binary compatible with SQL,
so maybe we can have some similar optimization as well.
(It is a pity that timestamp(tz) are not binary, or else we may
just need one operator).
Not to veer from the thread, but something about
On 2023-08-01 07:58, Julien Rouhaud wrote:
On Tue, Aug 01, 2023 at 07:36:36PM +0800, jacktby wrote:
Hi, I’m trying to develop a new grammar for pg
It's unclear to me whether you want to entirely replace the flex/bison
parser
with something else or just add some new bison rule.
Or express a
On 2023-07-14 18:22, David G. Johnston wrote:
For PostgreSQL this is even moreso (i.e, huge means count > 1) since
the
order of rows in the returning clause is not promised to be related to
the
order of the rows as seen in the supplied insert command. A manual
insert
returning should ask for n
1 - 100 of 627 matches
Mail list logo
