On Wed, Nov 6, 2019 at 11:25 AM Andres Freund <and...@anarazel.de> wrote: > I think it's more than just that. It's also that I think presenting a > hardcoded value to the outside of / above an AM is architecturally > wrong. If anything this is an implementation detail of the AM, that the > AM ought to be concerned with internally, not something it should > present to the outside.
I mean, it depends on your vision of how things ought to be abstracted. If you want the TOAST stuff to be logically "below" the table AM layer, then this is an abstraction violation. But if you think of TOAST as being a parallel system to table AM, then it's fine. It also depends on your goals. If you want to give the table AM maximum freedom to do what it likes, the design I proposed is not very good. If you want to make it easy for someone to plug in a new AM that does toasting like the current heap but with a different chunk size, that design lets you do so with a very minimal amount of code. I don't really care very much about the details here, but I don't want to just keep kicking the can down the road. If we can agree on *some* design that lets a new table AM have a TOAST table that uses an AM other than the heap, and that I can understand and implement with some halfway-reasonable amount of work, I'll do it. It doesn't have to be the thing I proposed. But I think it would be better to do that thing than nothing. We're not engraving anything we do here on stone tablets. > I also, and separately from that architectural concern, think that > hardcoding values like this in the control file is a bad practice, and > we shouldn't expand it. It basically makes it practically impossible to > ever change their default value. I generally agree, although I think there might be exceptions. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company