Two Approved Orders Are Not Any Two Orders

In one line

A change approval is not permission to change some number of rows. It is an agreement about which rows of which customer will change, from which state to which state.

Why this was needed

A festival operator asked us to cancel some snack orders because of rain. In the morning we queried two pending orders and got them approved. At lunch, when we went to run the change, one order had had its quantity changed by another owner, and a new pending order had come in from the same customer. If we rerun the morning's WHERE condition, we may cancel orders that did not exist at approval time. The fact that the SELECT was right and the fact that a later UPDATE respects the approved scope are not the same thing.

In the previous lessons, we narrowed a broad request and prepared a backup and abort criteria. Now we add a new variable, time. While a person reads the approval document, the database keeps moving. If you lock the whole table from the read until the apply, other work in the meantime stops. So we leave the observation at approval time as small explicit data, and at run time we compare whether that observation is still valid. If the comparison fails, you stop and get a new approval; you must not quietly change the plan to the current values.

How it works

In this lab, the approval covers three values: id, revision, and qty. The customer discriminator, tenant, is passed as a separate argument. For example, if the approval was given when order 1 of customer blue had revision=3 and qty=7, the apply condition contains all of these values along with the pending state. With only the ID, you can overwrite a value another owner changed, and with only the version, you can change another customer's row. It is not a device that checks one value but a contract that preserves the whole fact that was approved.

승인 때: 고객 blue / 주문 1 / 버전 3 / 수량 7 / pending
적용 때: 고객 blue / 주문 1 / 버전 4 / 수량 7 / pending
판단: 수량이 같아도 버전이 바뀌었으므로 재확인

The version is not the last number but a marker that distinguishes the change history. The quantity may have changed from 7 to 8 and then back to 7. Comparing values alone cannot distinguish this round trip. This contract assumes that every normal business change increases the revision. If another program fixes the table without that rule, the scope of protection changes, so in production you also have to manage the write paths and permissions. A single token in this lab does not control every program that writes.

The approval set is built as a copy sorted by ID. The aim is not to treat the same two targets as a different change just because they arrived in the opposite order. Conversely, if the same ID comes in twice, an ambiguity arises in which one row is handled twice, so it is rejected. An empty list is also not treated as a success. If you accept a run with a count of 0, a bug that lost its input can be recorded as a normal job that ended without incident. In this lesson we use small batches of 1 to 16 items.

Number validation is not mere defensive code either. In Python, True is a subtype of int, so under a loose check it can get in like order ID 1. A boolean turning into a number in approval data is a data interpretation error. Set exact integer ranges for id, revision, and qty, and reject bool. Each target is also copied into a new dict so that, even if other code modifies the returned plan, the original input does not change along with it.

What it looks like in the field

What the customer asks most is not SQL syntax but the impact scope. You have to be able to explain why only these two orders change, why other customers are not affected, and who judges again if something has changed since the approval. So the input of the change tool must be connected to the plan that was shown to the owner. If the CSV the engineer read and the list actually run differ from each other, it is not safe even with an approval procedure.

Real FDE work is tied to understanding the customer's problem, solving it with data and applications, and taking responsibility through to deployment. The public Palantir job posting below also asks for collaboration with customers and architecture and data-centered implementation. But this does not mean the posting asks for a specific PostgreSQL technique or this example's schema. Here we practice, with a small fictional case, the change-scope explanation and implementation verification that the role needs. No real customer data or personal information is used.

We also distinguish leaving a plan from being granted permission. Putting a tenant string into a function does not mean the caller has gained the permission to change that customer. This function checks for concurrent change conflicts on the premise that an authorized owner calls it. In a production API, login, customer-scoped permissions, the approving party, and the audit retention policy must be enforced separately. Do not use a test DB account as an example of a real service production account.

What you will do in the next check

In the quiz that follows, you distinguish the same count with different IDs, the same value with a different version, duplicate IDs, and an empty approval. In the capstone lab afterward, you make the plan observed in preview stale between two real PostgreSQL connections and then check whether the apply is rejected. It is practice in rechecking the change premise instead of secretly changing only the failed target to the new value.

References: Palantir FDSE job posting, PostgreSQL UPDATE. The posting was checked on 2026-09-13 and does not imply a hiring guarantee or the scope of any exam.