On Thu, 2023-08-31 at 08:37 -0400, Robert Haas wrote: > What I feel is kind of weird about this syntax is that it seems like > it's entangled with the FDW mechanism but doesn't really overlap with > it.
I like the fact that it works with user mappings and benefits from the other thinking that's gone into that system. I would call that a "feature" not an "entanglement". > You could have something that is completely separate (CREATE > SUBSCRIPTION CONNECTION) I thought about that but it would be a new object type with a new catalog and I didn't really see an upside. It would open up questions about permissions, raw string vs individual options, whether we need user mappings or not, etc., and those have all been worked out already with foreign servers. > or something that truly does have some > overlap (no new syntax and a dummy fdw, as Tom proposes, or somehow > knowing that postgres_fdw is special, as Ashutosh proposes). I ran into a (perhaps very minor?) challenge[1] with the dummy FDW: https://www.postgresql.org/message-id/c47e8ba923bf0a13671f7d8230a81d465c21fb04.ca...@j-davis.com suggestions welcome there, of course. Regarding core code depending on postgres_fdw: how would that work? Would that be acceptable? > But this > seems like sort of an odd middle ground. I assume here that you're talking about the CREATE SERVER ... FOR CONNECTION ONLY syntax. I don't think it's odd. We have lots of objects that are a lot like another object but treated differently for various reasons. A foreign table is an obvious example. > I also think that the decision to make pg_create_connection a member > of pg_create_subscription by default, but encouraging users to think > about revoking it, is kind of strange. I don't think we really want > to > encourage users to tinker with predefined roles in this kind of way. > I > think there are better ways of achieving the goals here. Such as? Regards, Jeff Davis