Few more details on this:
(gdb) p val
$1 = 0
(gdb) p i
$2 = 3
(gdb) f 3
#3 0x01a1ef70 in ExecCopySlotMinimalTuple (slot=0x202e4f8) at
../../../../src/include/executor/tuptable.h:472
472 return slot->tts_ops->copy_minimal_tuple(slot);
(gdb) p *slot
$3 = {type = T_TupleTableSlot, tts_flags
On Fri, 15 Sept 2023 at 22:37, Heikki Linnakangas wrote:
> > I've added a call to LockAssertNoneHeld(false) in there.
>
> I don't see it in the patch?
hmm. I must've git format-patch before committing that part.
I'll try that again... see attached.
David
On Mon, Sep 18, 2023 at 6:10 AM Peter Smith wrote:
>
> IIUC some future feature syncing of sequences is likely to share a lot
> of the tablesync worker code (maybe it is only differentiated by the
> relid being for a RELKIND_SEQUENCE?).
>
> The original intent of this stats worker-type patch was
On Mon, 18 Sept 2023 at 01:42, Andy Fan wrote:
> On Fri, Sep 15, 2023 at 3:15 PM David Rowley wrote:
>> Instead of doing that, why don't you just create a completely new
>> AppendPath containing all the cheapest_startup_paths and add that to
>> the append rel. You can optimise this and only do
On Sun, Sep 17, 2023 at 2:10 AM Nathan Bossart wrote:
>
> On Sat, Sep 16, 2023 at 06:09:48PM +0530, Amit Kapila wrote:
>
> This still leaves the possibility for confusion with the documentation's
> use of "leader apply worker", but I haven't touched that for now.
>
We may want to fix that
On Fri, Sep 15, 2023 at 12:11 AM Paul Jungwirth
wrote:
>
>
> I'll keep working on a patch to support multiple range keys, but I
> wanted to work through the rest of the feedback first. Also there is
> some fixing to do with partitions I believe, and then I'll finish the
> PERIOD support. So this
On Sunday, September 17, 2023, Chapman Flack wrote:
>
> In this one, both identifiers are part of the type name, and the
> separator a little more flamboyant.
>
> select to_regtype('character /* hi!
> am I part of the type name? /* what, me too? */ ok! */ -- huh!
> varying');
> to_regtype
>
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.
On Sun, Sep 17, 2023 at 6:25 PM Chapman Flack wrote:
> 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
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,
On Sun, Sep 17, 2023 at 5:34 PM Erik Wienhold wrote:
> On 18/09/2023 00:57 CEST Vik Fearing wrote:
>
> > On 9/18/23 00:41, Erik Wienhold wrote:
> > > On 18/09/2023 00:13 CEST David E. Wheeler
> wrote:
> > >
> > >> david=# select to_regtype('inteval second');
> > >> ERROR: syntax error at or
IIUC some future feature syncing of sequences is likely to share a lot
of the tablesync worker code (maybe it is only differentiated by the
relid being for a RELKIND_SEQUENCE?).
The original intent of this stats worker-type patch was to be able to
easily know the type of the process without
On Mon, 2023-09-18 at 00:57 +0200, Vik Fearing wrote:
> On 9/18/23 00:41, Erik Wienhold wrote:
> > On 18/09/2023 00:13 CEST David E. Wheeler wrote:
> > > The docs for `to_regtype()` say, “this function will return NULL rather
> > > than
> > > throwing an error if the name is not found.” And it’s
On Wed, Jul 26, 2023 at 6:41 AM Peter Geoghegan wrote:
> > MDAM seems to require exponential storage for "scan key operations"
> > for conditions on N columns (to be precise, the product of the number
> > of distinct conditions on each column); e.g. an index on mytable
> > (a,b,c,d,e,f,g,h) with
On Sep 17, 2023, at 19:28, Tom Lane wrote:
>> No, that is precisely the point. The result should be null instead of
>> an error.
>
> Yeah, ideally so, but the cost/benefit of making it happen seems
> pretty unattractive for now. See the soft-errors thread at [1],
> particularly [2] (but
On 18/09/2023 00:57 CEST Vik Fearing wrote:
> On 9/18/23 00:41, Erik Wienhold wrote:
> > On 18/09/2023 00:13 CEST David E. Wheeler wrote:
> >
> >> david=# select to_regtype('inteval second');
> >> ERROR: syntax error at or near "second"
> >> LINE 1: select to_regtype('inteval second');
> >>
Vik Fearing writes:
> No, that is precisely the point. The result should be null instead of
> an error.
Yeah, ideally so, but the cost/benefit of making it happen seems
pretty unattractive for now. See the soft-errors thread at [1],
particularly [2] (but searching in that thread for
On 9/18/23 00:41, Erik Wienhold wrote:
On 18/09/2023 00:13 CEST David E. Wheeler wrote:
The docs for `to_regtype()` say, “this function will return NULL rather than
throwing an error if the name is not found.” And it’s true most of the time:
david=# select to_regtype('foo'),
On 18/09/2023 00:13 CEST David E. Wheeler wrote:
> The docs for `to_regtype()` say, “this function will return NULL rather than
> throwing an error if the name is not found.” And it’s true most of the time:
>
> david=# select to_regtype('foo'), to_regtype('clam');
> to_regtype | to_regtype
>
The docs for `to_regtype()` say, “this function will return NULL rather than
throwing an error if the name is not found.” And it’s true most of the time:
david=# select to_regtype('foo'), to_regtype('clam');
to_regtype | to_regtype
+
[null] | [null]
But not others:
On Sep 17, 2023, at 12:20, Tom Lane wrote:
> After thinking about it for awhile, I think we need some more
> discursive explanation of what's allowed, perhaps along the lines
> of the attached. (I still can't shake the feeling that this is
> duplicative; but I can't find anything comparable
On 17/09/2023 21:31 CEST Erik Wienhold wrote:
> This affects the following meta commands:
>
> \db+ \dD+ \df+ \dL+ \dl+ \dn+ \dp \dT+ \l
also \des+ and \dew+
--
Erik
I wrote a patch to change psql's display of zero privileges after a user's
reported confusion with the psql output for zero vs. default privileges [1].
Admittedly, zero privileges is a rare use case [2] but I think psql should not
confuse the user in the off chance that this happens.
With this
"David E. Wheeler" writes:
> On Sep 15, 2023, at 20:36, Tom Lane wrote:
>> I think that that indicates that you're putting the info in the
>> wrong place. Perhaps the right answer is to insert something
>> more explicit in section 11.2, which is the first place where
>> we really spend any
Hi David,
Thanks for taking a look at this!
On Fri, Sep 15, 2023 at 3:15 PM David Rowley wrote:
> On Thu, 7 Sept 2023 at 04:37, Andy Fan wrote:
> > Currently add_paths_to_append_rel overlooked the startup cost for
> creating
> > append path, so it may have lost some optimization chances.
On 9/14/23 20:33, Andres Freund wrote:
I'd probably just go for something like "snapshot \"%s\" does not exist",
similar to what we report for unknown tables etc. Arguably changing the
errcode to ERRCODE_UNDEFINED_OBJECT would make this more precise?
+1 better informative message compare to
Op 9/14/23 om 10:14 schreef Amit Langote:
Hi Amit,
Just now I built a v14-patched server and I found this crash:
select json_query(jsonb '
{
"arr": [
{"arr": [2,3]}
, {"arr": [4,5]}
]
}'
, '$.arr[*].arr ? (@ <= 3)' returning anyarray WITH WRAPPER) --crash
;
server closed the
27 matches
Mail list logo
