You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Make URL and POST parameters immutable, separate from SET variables
- URL and POST parameters are now immutable after request initialization
- SET command creates user-defined variables in separate namespace
- Variable lookup: SET variables shadow request parameters
- Added sqlpage.variables('set') to inspect user-defined variables
- Simplified API: most functions now use &RequestInfo instead of &mut
- All tests passing (151 total)
Copy file name to clipboardExpand all lines: examples/official-site/extensions-to-sql.md
+22-7Lines changed: 22 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -75,10 +75,15 @@ SELECT (select 1) AS one;
75
75
## Variables
76
76
77
77
SQLPage communicates information about incoming HTTP requests to your SQL code through prepared statement variables.
78
-
You can use
79
-
-`$var` to reference a GET variable (an URL parameter),
80
-
-`:var` to reference a POST variable (a value filled by an user in a form field),
81
-
-`set var = ...` to set the value of `$var`.
78
+
79
+
### Variable Types and Mutability
80
+
81
+
There are two types of variables in SQLPage:
82
+
83
+
1.**Request parameters** (immutable): URL parameters and form data from the HTTP request
84
+
2.**User-defined variables** (mutable): Variables created with the `SET` command
85
+
86
+
Request parameters cannot be modified after the request is received. This ensures the original request data remains intact throughout request processing.
82
87
83
88
### POST parameters
84
89
@@ -111,20 +116,30 @@ When a URL parameter is not set, its value is `NULL`.
111
116
112
117
### The SET command
113
118
114
-
`SET`stores a value in SQLPage (not in the database). Only strings and `NULL` are stored.
119
+
`SET`creates or updates a user-defined variable in SQLPage (not in the database). Only strings and `NULL` are stored.
115
120
116
121
```sql
117
122
-- Give a default value to a variable
118
123
SET post_id = COALESCE($post_id, 0);
124
+
125
+
-- User-defined variables shadow URL parameters with the same name
126
+
SET my_var ='custom value'; -- This value takes precedence over ?my_var=...
119
127
```
120
128
129
+
**Variable Lookup Precedence:**
130
+
-`$var`: checks user-defined variables first, then URL parameters
131
+
-`:var`: checks user-defined variables first, then POST parameters
132
+
133
+
This means `SET` variables always take precedence over request parameters when using `$var` or `:var` syntax.
134
+
135
+
**How SET works:**
121
136
- If the right-hand side is purely literals/variables, SQLPage computes it directly. See the section about *static simple select* above.
122
137
- If it needs the database (for example, calls a database function), SQLPage runs an internal `SELECT` to compute it and stores the first column of the first row of results.
123
138
124
139
Only a single textual value (**string or `NULL`**) is stored.
125
-
`set id = 1` will store the string `'1'`, not the number `1`.
140
+
`SET id = 1` will store the string `'1'`, not the number `1`.
126
141
127
-
On databases with a strict type system, such as PostgreSQL, if you need a number, you will need to cast your variables: `select * from post where id = $id::int`.
142
+
On databases with a strict type system, such as PostgreSQL, if you need a number, you will need to cast your variables: `SELECT * FROM post WHERE id = $id::int`.
Copy file name to clipboardExpand all lines: examples/official-site/sqlpage/migrations/20_variables_function.sql
+19-2Lines changed: 19 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -9,10 +9,27 @@ VALUES (
9
9
'variables',
10
10
'0.15.0',
11
11
'variable',
12
-
'Returns a JSON string containing all variables passed as URL parameters or posted through a form.
12
+
'Returns a JSON string containing variables from the HTTP request and user-defined variables.
13
13
14
14
The database''s json handling functions can then be used to process the data.
15
15
16
+
## Variable Types
17
+
18
+
SQLPage distinguishes between three types of variables:
19
+
20
+
- **GET variables**: URL parameters from the query string (immutable)
21
+
- **POST variables**: Form data from POST requests (immutable)
22
+
- **SET variables**: User-defined variables created with the `SET` command (mutable)
23
+
24
+
## Usage
25
+
26
+
- `sqlpage.variables()` - returns all variables (GET, POST, and SET combined, with SET variables taking precedence)
27
+
- `sqlpage.variables(''get'')` - returns only URL parameters
28
+
- `sqlpage.variables(''post'')` - returns only POST form data
29
+
- `sqlpage.variables(''set'')` - returns only user-defined variables created with `SET`
30
+
31
+
When a SET variable has the same name as a GET or POST variable, the SET variable takes precedence in the combined result.
32
+
16
33
## Example: a form with a variable number of fields
17
34
18
35
### Making a form based on questions in a database table
@@ -95,6 +112,6 @@ VALUES (
95
112
'variables',
96
113
1,
97
114
'method',
98
-
'Optional. The HTTP request method (GET or POST). Must be a literal string. When not provided, all variables are returned.',
115
+
'Optional. Filter variables by source: ''get'' (URL parameters), ''post'' (form data), or ''set'' (user-defined variables). When not provided, all variables are returned with SET variables taking precedence over request parameters.',
log::warn!("Deprecation warning! Setting the value of ${name}, but there is already a form field named :{name}. This will stop working soon. Please rename the variable, or use :{name} directly if you intended to overwrite the posted form field value.");
"Deprecation warning! There is both a URL parameter named '{x}' with value '{get_val}' and a form field named '{x}' with value '{v}'. \
168
-
SQLPage is using the value from the form submission, but this is ambiguous, can lead to unexpected behavior, and will stop working in a future version of SQLPage. \
169
-
To fix this, please rename the URL parameter to something else, and reference the form field with :{x}."
170
-
);
171
-
}else{
172
-
log::warn!("Deprecation warning! ${x} was used to reference a form field value (a POST variable) instead of a URL parameter. This will stop working soon. Please use :{x} instead.");
log::warn!("Deprecation warning! ${x} was used to reference a form field value (a POST variable) instead of a URL parameter. This will stop working soon. Please use :{x} instead.");
0 commit comments