Hi,
On 2019-03-19 15:25:44 +1100, Haribabu Kommi wrote:
> On Tue, Mar 19, 2019 at 2:32 PM Andres Freund wrote:
> > I'm kinda wondering about replacing the TableTuple prefix with TableMod,
> > seems less confusing to me.
> One more way, how about just TupleUpdated and etc. Removing of Table?
> Th
On Tue, Mar 19, 2019 at 2:32 PM Andres Freund wrote:
> On 2019-03-18 16:24:40 -0700, Andres Freund wrote:
> > Hi,
> >
> > On 2019-03-13 08:29:47 -0400, Robert Haas wrote:
> > > On Tue, Mar 12, 2019 at 8:39 PM Andres Freund
> wrote:
> > > > > I like that option.
> > > >
> > > > In that vein, does
On 2019-03-18 16:24:40 -0700, Andres Freund wrote:
> Hi,
>
> On 2019-03-13 08:29:47 -0400, Robert Haas wrote:
> > On Tue, Mar 12, 2019 at 8:39 PM Andres Freund wrote:
> > > > I like that option.
> > >
> > > In that vein, does anybody have an opinion about the naming of
> > > a) HeapUpdateFailureD
Hi,
On 2019-03-13 08:29:47 -0400, Robert Haas wrote:
> On Tue, Mar 12, 2019 at 8:39 PM Andres Freund wrote:
> > > I like that option.
> >
> > In that vein, does anybody have an opinion about the naming of
> > a) HeapUpdateFailureData, which will be used for different AMs
> > b) HTSU_Result itself
On Tue, Mar 12, 2019 at 8:39 PM Andres Freund wrote:
> > I like that option.
>
> In that vein, does anybody have an opinion about the naming of
> a) HeapUpdateFailureData, which will be used for different AMs
> b) HTSU_Result itself, which'll be the return parameter for
>update/delete via tabl
On 2018-12-19 14:21:29 -0500, Robert Haas wrote:
> On Tue, Dec 18, 2018 at 11:17 PM Andres Freund wrote:
> > The current pluggable table storage patchset [1] introduces the ability
> > to specify the access method of a table (CREATE TABLE ... USING
> > "ident"). The patchset currently names the cu
On 2019-01-18 14:19:41 -0800, Andres Freund wrote:
> Hi,
>
> On 2019-01-16 08:20:37 -0800, Andres Freund wrote:
> > On January 16, 2019 8:08:09 AM PST, Robert Haas
> > wrote:
> > >On Tue, Jan 15, 2019 at 10:23 PM Haribabu Kommi
> > > wrote:
> > >> access/relation.[c|h] name is fine. Or how about
Hi,
On 2019-01-16 08:20:37 -0800, Andres Freund wrote:
> On January 16, 2019 8:08:09 AM PST, Robert Haas wrote:
> >On Tue, Jan 15, 2019 at 10:23 PM Haribabu Kommi
> > wrote:
> >> access/relation.[c|h] name is fine. Or how about access/rel.[c|h],
> >> because nodes/relation.h is related to planner
On January 16, 2019 8:08:09 AM PST, Robert Haas wrote:
>On Tue, Jan 15, 2019 at 10:23 PM Haribabu Kommi
> wrote:
>> access/relation.[c|h] name is fine. Or how about access/rel.[c|h],
>> because nodes/relation.h is related to planner. utils/rel.h is some
>how
>> related to relation caches.
>
>In
Robert Haas writes:
> On Tue, Jan 15, 2019 at 10:23 PM Haribabu Kommi
> wrote:
>> access/relation.[c|h] name is fine. Or how about access/rel.[c|h],
>> because nodes/relation.h is related to planner. utils/rel.h is some how
>> related to relation caches.
> Insofar as we can reasonably do so, I'd
On Tue, Jan 15, 2019 at 10:23 PM Haribabu Kommi
wrote:
> access/relation.[c|h] name is fine. Or how about access/rel.[c|h],
> because nodes/relation.h is related to planner. utils/rel.h is some how
> related to relation caches.
Insofar as we can reasonably do so, I'd rather pick unique names for
On Tue, Jan 15, 2019 at 1:43 PM Andres Freund wrote:
> Hi,
>
> On 2019-01-11 12:01:36 -0500, Robert Haas wrote:
> > On Thu, Jan 10, 2019 at 7:05 PM Andres Freund
> wrote:
> > > ISTM that the first block would best belong into new files like
> > > access/rel[ation].h and access/common/rel[ation].
On Thu, Jan 10, 2019 at 7:05 PM Andres Freund wrote:
> ISTM that the first block would best belong into new files like
> access/rel[ation].h and access/common/rel[ation].h.
+1.
> I think the second
> set should be renamed to be table_open() (with backward compat
> redirects, there's way way too
On Fri, Jan 11, 2019 at 11:05 AM Andres Freund wrote:
> Hi,
>
> On 2018-12-19 14:21:29 -0500, Robert Haas wrote:
> > On Tue, Dec 18, 2018 at 11:17 PM Andres Freund
> wrote:
> > > Another would be to be aggressive in renaming, and deconflict by
> > > renaming functions like heap_create[_with_cata
Hi,
On 2018-12-19 14:21:29 -0500, Robert Haas wrote:
> On Tue, Dec 18, 2018 at 11:17 PM Andres Freund wrote:
> > Another would be to be aggressive in renaming, and deconflict by
> > renaming functions like heap_create[_with_catalog] etc to sound more
> > accurate. I think that has some appeal, be
> On 19 Dec 2018, at 20:21, Robert Haas wrote:
> I vote for calling the current heap "heap" - i.e. what the patchset is
> currently doing. As others have already noted, that's a perfectly
> good word for storing stuff in no particular order, and it's also a
> term with a very long history.
FWIW
On Tue, Dec 18, 2018 at 11:17 PM Andres Freund wrote:
> The current pluggable table storage patchset [1] introduces the ability
> to specify the access method of a table (CREATE TABLE ... USING
> "ident"). The patchset currently names the current storage method
> (i.e. heapam.c et al) "heap" (wher
On Wed, Dec 19, 2018 at 08:32:28AM -0300, Alvaro Herrera wrote:
> Hi,
>
> On 2018-Dec-19, Andres Freund wrote:
>
> > Well, that depends on what "non-heap layouts" you're thinking of. I
> > think there'd be some further work needed to make efficient IOTs
> > possible, but the patchset gets us a l
Call it "pile" and "hoard":
https://www.thesaurus.com/browse/heap
https://www.thesaurus.com/browse/pile
https://www.thesaurus.com/browse/hoard
ср, 19 дек. 2018 г. в 07:17, Andres Freund :
> Hi,
>
> The current pluggable table storage patchset [1] introduces the ability
> to specify the access me
Hi,
On 2018-Dec-19, Andres Freund wrote:
> Well, that depends on what "non-heap layouts" you're thinking of. I
> think there'd be some further work needed to make efficient IOTs
> possible, but the patchset gets us a long way to be able to do that in a
> pluggable fashion. Biggest problem would
Hi,
On 2018-12-19 12:02:38 +0100, Peter Eisentraut wrote:
> On 19/12/2018 11:15, Thomas Munro wrote:
> > It just means tuples stored in no particular order (as opposed to eg
> > btree tables, in systems that support those).
>
> So would the proposed pluggable storage API allow index-organized bas
On 19/12/2018 11:15, Thomas Munro wrote:
> It just means tuples stored in no particular order (as opposed to eg
> btree tables, in systems that support those).
So would the proposed pluggable storage API allow index-organized base
storage and other non-heap layouts?
--
Peter Eisentraut
On Wed, Dec 19, 2018 at 7:44 PM Arkhena wrote:
>> I'm wondering where the choice of the name "heap" originally came from
>> and what it refers to.
>
> It seems to me that "heap" is an Oracle word (as explained here[1]).
>
> > By default, a table is organized as a heap, which means that the databas
>
>
> I'm wondering where the choice of the name "heap" originally came from
> and what it refers to.
It seems to me that "heap" is an Oracle word (as explained here[1]).
> By default, a table is organized as a heap, which means that the database
places rows where they fit best rather than in a
On 19/12/2018 05:17, Andres Freund wrote:
> I'm concerned that naming it heap, and the corresponding functions
> fitting with that name, will be confusing. There's a lot of functions
> that have a heap_ prefix (or similar) that aren't really dependent on
> how the storage works, but much more gener
Hi,
The current pluggable table storage patchset [1] introduces the ability
to specify the access method of a table (CREATE TABLE ... USING
"ident"). The patchset currently names the current storage method
(i.e. heapam.c et al) "heap" (whereas e.g. zheap's in named, drumroll,
zheap).
I'm concerne
26 matches
Mail list logo
