On Mon, Mar 25, 2019 at 12:33 PM Tom Lane wrote:
> Robert Haas writes:
> > Maybe we don't really need the word "tuple". Like we could just make
> > it slot_store_heap() or SlotStoreHeap(). A slot can only store a
> > tuple, after all.
>
> I don't think it's wise to think of these things as just
Hi,
On 2019-03-25 12:45:36 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-03-25 12:33:38 -0400, Tom Lane wrote:
> >> I don't think it's wise to think of these things as just "slots";
> >> that name is way too generic. They are "tuple slots", and so that
> >> word has to stay in the r
Andres Freund writes:
> On 2019-03-25 12:33:38 -0400, Tom Lane wrote:
>> I don't think it's wise to think of these things as just "slots";
>> that name is way too generic. They are "tuple slots", and so that
>> word has to stay in the relevant function names.
> Hm. But we already have slot_{gets
Hi,
On 2019-03-25 12:33:38 -0400, Tom Lane wrote:
> Robert Haas writes:
> > Maybe we don't really need the word "tuple". Like we could just make
> > it slot_store_heap() or SlotStoreHeap(). A slot can only store a
> > tuple, after all.
>
> I don't think it's wise to think of these things as ju
Robert Haas writes:
> Maybe we don't really need the word "tuple". Like we could just make
> it slot_store_heap() or SlotStoreHeap(). A slot can only store a
> tuple, after all.
I don't think it's wise to think of these things as just "slots";
that name is way too generic. They are "tuple slot
Hi,
On 2019-03-25 12:05:52 -0400, Robert Haas wrote:
> On Mon, Mar 25, 2019 at 11:57 AM Andres Freund wrote:
> > I think I might go for slot_store_heap_tuple etc, given that a lot of
> > those accessors have been slot_ for about ever. What do you think?
>
> I don't have a super-strong feeling ab
On Mon, Mar 25, 2019 at 11:57 AM Andres Freund wrote:
> I think I might go for slot_store_heap_tuple etc, given that a lot of
> those accessors have been slot_ for about ever. What do you think?
I don't have a super-strong feeling about it, although changing the
case convention might confuse a fe
Hi,
On 2019-03-25 11:20:13 -0400, Robert Haas wrote:
> While reviewing some zheap code last week, I noticed that the naming
> of the ExecStore*Tuple() functions seems a bit unfortunate. One
> reason is that we are now using slots in all kinds of places other
> than the executor, so that the "Exec
On 2019-Mar-25, Robert Haas wrote:
> On Mon, Mar 25, 2019 at 11:27 AM Alvaro Herrera
> wrote:
> > Should we keep ExecStoreTuple as a compatibility macro for third party
> > code?
>
> I think that might be rather dangerous, actually, because slots now
> have a type, which they didn't before. You
On Mon, Mar 25, 2019 at 11:27 AM Alvaro Herrera
wrote:
> Should we keep ExecStoreTuple as a compatibility macro for third party
> code?
I think that might be rather dangerous, actually, because slots now
have a type, which they didn't before. You have to use the correct
function for the kind of
I agree about taking out the "Exec" part of the name.
On 2019-Mar-25, Robert Haas wrote:
> I'm not sure exactly what names would be better. Perhaps just change
> the "Exec" prefix to "Slot", e.g. SlotStoreHeapTuple(). Or maybe put
> InSlot at the end, like StoreHeapTupleInSlot(). Or just take
Hi,
While reviewing some zheap code last week, I noticed that the naming
of the ExecStore*Tuple() functions seems a bit unfortunate. One
reason is that we are now using slots in all kinds of places other
than the executor, so that the "Exec" prefix seems a bit out of place.
However, you could arg
12 matches
Mail list logo
