On 1/7/21 2:32 PM, Simon Riggs wrote:
On Sat, Jan 2, 2021 at 6:44 PM Jeff Davis wrote:
On Wed, 2020-12-30 at 21:23 +, Simon Riggs wrote:
But you cannot seriously argue that a one line patch that changes
user
visible behavior can be acceptable in Postgres core without tests or
docs or
On Sat, Jan 2, 2021 at 6:44 PM Jeff Davis wrote:
>
> On Wed, 2020-12-30 at 21:23 +, Simon Riggs wrote:
> > But you cannot seriously argue that a one line patch that changes
> > user
> > visible behavior can be acceptable in Postgres core without tests or
> > docs or code comments.
>
> Hi
On Wed, 2020-12-30 at 21:23 +, Simon Riggs wrote:
> But you cannot seriously argue that a one line patch that changes
> user
> visible behavior can be acceptable in Postgres core without tests or
> docs or code comments.
Hi Simon,
Often, good documented APIs come about after a few extensions
On Tue, 15 Dec 2020 at 23:59, Jeff Davis wrote:
>
> On Tue, 2020-12-15 at 17:37 +, Simon Riggs wrote:
> >
> > I definitely don't agree with the premise that all existing heap
> > options should be common across all new or extension tableAMs. There
> > are dozens of such options and I don't
On Tue, Dec 15, 2020 at 03:59:02PM -0800, Jeff Davis wrote:
> How should that work with the existing code? Should we have separate AM
> hooks for each of these interaction points, and then have the AM figure
> out how to handle its options? What about the toast.* options?
It seems to me that we
On Tue, 2020-12-15 at 17:37 +, Simon Riggs wrote:
>
> I definitely don't agree with the premise that all existing heap
> options should be common across all new or extension tableAMs. There
> are dozens of such options and I don't believe that they would all
> have meaning in all future
On Tue, 1 Sept 2020 at 18:21, Jeff Davis wrote:
> I went with the simple approach because fixing that problem seemed a
> bit over-engineered. Here are some thoughts on what we could do:
The simple patch is admirable, but not something we should put into core.
I definitely don't agree with the
‐‐‐ Original Message ‐‐‐
On Tuesday, 1 September 2020 20:21, Jeff Davis wrote:
>
> I'm fine removing the "validate" parameter completely for the sake of
> consistency.
FWIW, the more I think about this, I would agree with the removal.
However, isn't this mechanism used for other
On Tue, 2020-09-01 at 12:20 -0400, Alvaro Herrera wrote:
> Hmm, I think that if we're going to do this, we should do it for all
> AMs, not just table AMs, since surely index AMs also want extensible
> reloptions; and I think that makes the 'validate' mechanism dead code
> and so we should remove
On 2020-Aug-31, Jeff Davis wrote:
> fillRelOptions() validates when filling in a struct to make sure there
> aren't "leftover" options. It does this using a hard-coded parsing
> table that is not extensible.
Hmm, I think that if we're going to do this, we should do it for all
AMs, not just table
‐‐‐ Original Message ‐‐‐
On Tuesday, 1 September 2020 09:18, Jeff Davis wrote:
> A custom table access method might want to add a new reloption to
> control something specific to that table access method. Unfortunately,
> if you add a new option of type RELOPT_KIND_HEAP, it will
A custom table access method might want to add a new reloption to
control something specific to that table access method. Unfortunately,
if you add a new option of type RELOPT_KIND_HEAP, it will immediately
fail because of the validation that happens in fillRelOptions().
Right now, heap
12 matches
Mail list logo
