Thank you for turning this around so quickly!
>
> > > On Thu, Nov 23, 2023 at 1:10 PM Nikhil Benesch
> > wrote:
> > > >
> > > > While working on Materialize's streaming logical replication from
> > > > Postgres [0], my colleagues Sean Loiselle and Petros Angelatos
> > > >
While working on Materialize's streaming logical replication from Postgres [0],
my colleagues Sean Loiselle and Petros Angelatos (CC'd) discovered today what
appears to be a correctness bug in pgoutput, introduced in v15.
The problem goes like this. A table with REPLICA IDENTITY FULL and some
data
I took a look at 0002 because I attempted a similar but more surgical
fix in [0].
I spotted a few opportunities for further reducing state tracked by
`ArrayCount`. You may not find all of these suggestions to be
worthwhile.
1) `in_quotes` appears to be wholly redundant with `parse_state ==
ARRAY_
On Mon, Jan 3, 2022 at 1:14 PM Tom Lane wrote:
> Hmm, I think you went a bit too far here. The existing code intends
> to draw a distinction between "not recognized" (i.e., "we don't know
> what that word was you used") and "not supported" (i.e., "we know
> that word, but it doesn't seem to make
Updated patch attached.
On Mon, Jan 3, 2022 at 10:26 AM Nikhil Benesch wrote:
>
> On Mon, Jan 3, 2022 at 10:20 AM Tom Lane wrote:
> > BTW, if you want to get rid of the quotes, I think that something
> > else has to be done to set off the type name from the rest. In
> &g
On Mon, Jan 3, 2022 at 10:20 AM Tom Lane wrote:
> BTW, if you want to get rid of the quotes, I think that something
> else has to be done to set off the type name from the rest. In
> this instance someone might think that we're complaining about a
> "time zone unit", whatever that is. I suggest
On Mon, Jan 3, 2022 at 10:11 AM Tom Lane wrote:
> Yeah, but we've been slowly converting to that method to reduce the number
> of distinct translatable strings for error messages. If doing so here
> would cut the labor for translators, I'm for it.
Great! I'll update the patch. Thanks for confirm
On Mon, Jan 3, 2022 at 3:17 AM Michael Paquier wrote:
> However, there is a specific routine called format_type_be() aimed at
> formatting type names for error strings. If you switch to that, my
> guess is that this makes the error messages of time/timetz and
> timestamp/timestamptz/interval more
The attached patch corrects a very minor typographical inconsistency
when date_part is invoked with invalid units on time/timetz data vs
timestamp/timestamptz/interval data.
(If stuff like this is too minor to bother with, let me know and I'll
hold off in the future... but since this was pointed o
On 11/5/20 8:58 PM, Tom Lane wrote:
"any" is a dinosaur IMO. It's definitely lower-level than anyelement;
for example the function has to be prepared to deal with raw "unknown"
literals. So I feel like the proposed solution here is a bit of a hack.
I see what you are saying, but since the cod
On 11/5/20 7:38 PM, David G. Johnston wrote:
My understanding is that "any" is defined to accept that behavior - allowing any pseudo-type and unknown. The
"anyelement" polymorphic pseudo-type is defined such that only concrete known types are allowed to match - and then the
rules of polymorphi
to_json is declared as taking "anyelement" as input, which means
you can't pass it something of unknown type:
postgres=# SELECT to_json('foo');
ERROR: could not determine polymorphic type because input has type unknown
But this works fine with the very similar json_build_array function:
On 11/1/20 9:56 PM, Tom Lane wrote:
Please add an entry to the upcoming commitfest, to make sure we don't
lose track of this:
https://commitfest.postgresql.org/30/
Done: https://commitfest.postgresql.org/30/2816/
byte encodings. We could at least avoid the extra
pass over the string by allocating a circular buffer of size |n| when n is
negative, but that wasn't clearly worthwhile. (I did implement the optimization
for the special case of -1, since its implementation was trivial.)
Cheers,
Nikhil
From a0
15 matches
Mail list logo
