On Mon, Jun 6, 2022 at 5:28 PM bened...@apache.org <bened...@apache.org> wrote:
> > One way to make it obvious is to require the user to explicitly type > the SELECTs and then to require that all SELECTs appear before > UPDATE/INSERT/DELETE. > > > > Yes, I agree that SELECT statements should be required to go first. > > > > However, I think this is sufficient and we can retain the shorter format > for RETURNING. There only remains the issue of conditions imposed upon > UPDATE/INSERT/DELETE statements when there are multiple statements that > affect the same primary key. I think we can (and should) simply reject such > queries for now, as it doesn’t make much sense to have multiple statements > for the same primary key in the same transaction. > > I guess I was thinking ahead to a future where and UPDATE write set may or may not intersect with a previous update due to allowing WHERE clause to use secondary keys, etc. That said, I'm not saying we SHOULD require explicit SELECT statements for every update. I'm sure that would be annoying more than useful.I was just following a train of thought. > > > > Returning the "result" from an UPDATE presents the question should it > be the data at the start of the transaction or end state? > > > > I am inclined to only return the new values (as proposed by Alex) for the > purpose of returning new auto-increment values etc. If you require the > prior value, SELECT is available to express this. > > That's a great point! > > > > I was thinking the following coordinator-side implementation would > allow to use also old drivers > > > > I am inclined to return just the first result set to old clients. I think > it’s fine to require a client upgrade to get multiple result sets. > > Possibly. I just wanted to share an idea for consideration. IMO the temp table idea might not be too hard to implement*, but sure the syntax does feel a bit bolted on. *) I'm maybe the wrong person to judge that, of course :-) henrik -- Henrik Ingo +358 40 569 7354 <358405697354> [image: Visit us online.] <https://www.datastax.com/> [image: Visit us on Twitter.] <https://twitter.com/DataStaxEng> [image: Visit us on YouTube.] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_channel_UCqA6zOSMpQ55vvguq4Y0jAg&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=bmIfaie9O3fWJAu6lESvWj3HajV4VFwgwgVuKmxKZmE&s=16sY48_kvIb7sRQORknZrr3V8iLTfemFKbMVNZhdwgw&e=> [image: Visit my LinkedIn profile.] <https://www.linkedin.com/in/heingo/>
