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
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
>> mentioned transform should be applied t
On Wed, Apr 16, 2025 at 03:25:19PM -0700, Michael Paquier wrote:
> If anybody objects about the points getting renamed here, please let
> me know.
Applied this one as 114f7fa81c72.
--
Michael
signature.asc
Description: PGP signature
> Sami Imseih writes:
> > I think the solution proposed by Frédéric seems reasonable: to switch
> > the debug_query_string
> > inside PortalDrop. However, I do not like the way the
> > debug_query_string changes values
> > after the CreatePortal call inside exec_bind_message; that seems incorrect.
Oh, just in case this wasn't complicated enough already: what
to do with polymorphic arguments/results?
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
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 17 Apr 2025, at 17:48, Jacob Champion
> wrote:
>
> On Thu, Apr 17, 2025 at 8:20 AM Tom Lane wrote:
>> I confirm this silences those warnings on my Fedora 41 box.
>
> Instead of doing
>
>lex = calloc(...);
>/* (error out on NULL return) */
>makeJsonLexContextCstringLen(lex, ..
On Sat, 19 Apr 2025 at 20:00, Alexander Lakhin wrote:
> I've gathered the following collection of typos and inconsistencies
> appeared since 2025-01-01:
Here are a few more fixes of a similar ilk. All new in 2025,
predominantly from the last few days before feature freeze.
The few I wasn't a ful
Hello hackers,
I've gathered the following collection of typos and inconsistencies
appeared since 2025-01-01:
aio_worker.c -> method_worker.c
amcheck_lock_relation -> amcheck_lock_relation_and_check
be_key -> be_cancel_key
belonds -> belongs
cann -> can
CheckConstraintFetch -> CheckNNConstra
Andrew Dunstan writes:
> On 2025-04-18 Fr 7:26 PM, Tom Lane wrote:
> +See C. CAUTION: use of either option requires that
> +the server's log_min_messages be at least DEBUG2, and that no other
> +client backend is launched concurrently. These requirements allow
> +C to wait to see the postmaster-
> On 19 Apr 2025, at 7:17 PM, Tom Lane wrote:
>
> Our fine manual claims the answer to $SUBJECT is 3.2.
>
> However, there is room to doubt that our code still actually
> works with 3.2, because the oldest version I can find being
> tested by the buildfarm is topminnow's 3.4.2. The next olde
I looked into this a bit more.
What occurs during exec_bind_message is that the debug_query_string of the
query is set early on. Later in that routine, a new portal is created
via CreatePortal,
which also drops the existing unnamed portal from the previous
execution and which
also logs the temp fi
Chapman Flack writes:
>Therefore:
> 5. You can create a transform for an array type, but can never refer to it
>in TRANSFORM FOR TYPE (you end up referring to the element type).
> 6. You can refer to a domain in TRANSFORM FOR TYPE, but that transform
>can never be created.
> These don'
On Sat, Apr 19, 2025 at 11:00:00AM +0300, Alexander Lakhin wrote:
> I've gathered the following collection of typos and inconsistencies
> appeared since 2025-01-01:
Good finds, Alexander, particularly for the set of function and
variable names used in the comments that do not match with the
realit
On 2025-04-18 Fr 7:26 PM, Tom Lane wrote:
I wrote:
What I think happened here is that a previous backend hadn't exited
yet when we start the test, and when its report does come out,
connect_fails prematurely stops waiting. (In the above, evidently
the child process we want to wait for is 599,
Re: Jacob Champion
> > libpq_append_conn_error(conn, "no custom OAuth flows are available,
> > and libpq-oauth could not be loaded library could not be loaded. Try
> > installing the libpq-oauth package from the same source that you
> > installed libpq from");
>
> Thanks! I think that's a little t
Sami Imseih writes:
> I think the solution proposed by Frédéric seems reasonable: to switch
> the debug_query_string
> inside PortalDrop. However, I do not like the way the
> debug_query_string changes values
> after the CreatePortal call inside exec_bind_message; that seems incorrect.
> So, I bel
Florents Tselai writes:
> On 19 Apr 2025, at 7:17 PM, Tom Lane wrote:
>> I think we need to do some combination of moving our
>> minimum-supported-version goalposts forward, making sure that
>> whatever we claim is the minimum Python version is actually
>> being tested in the buildfarm, and fixin
> On 19 Apr 2025, at 4:18 AM, Yurii Rashkovskii wrote:
>
> Hi,
>
> I propose to introduce `pg_creating_extension()` function that would return
> the OID of the extension being currently created (or `null` if none is).
>
> The core motivation for it is to be able to establish data provenance
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
Hello Michael,
19.04.2025 13:04, Michael Paquier wrote:
Good finds, Alexander, particularly for the set of function and
variable names used in the comments that do not match with the
reality. I've checked all these, and they're good for me.
Thank you for your attention to this!
GIN_TUPLE_ -
Our fine manual claims the answer to $SUBJECT is 3.2.
However, there is room to doubt that our code still actually
works with 3.2, because the oldest version I can find being
tested by the buildfarm is topminnow's 3.4.2. The next oldest
is shelduck's 3.4.10, and everything else has 3.5.2 or newer
BTW, there is another way in which the current rules for transform
application are not self-consistent. Postgres has three kinds of
container types: arrays, composites, and ranges. But the transform
code special-cases only arrays. I'd have thought that if the idea is
to specify transforms only f
On Thu, 2025-04-17 at 06:58 -0700, Noah Misch wrote:
> Should initcap_wbnext() pass in a locale-dependent "bool posix"
> argument like
> the others calls the commit changed?
Yes, I believe you are correct. Patch and tests attached.
> Long-term, pg_u_isword() should have a "bool posix" argument.
24 matches
Mail list logo