All foreign tables have a generic PATHPATTERN; for example, PATHPATTERN('$Var1/$Var2/$Var3/$Var4/$Var5/$Var6/$Var7/$Var8/$Var9/$Var10/$Var11').
To make path filtering in a query easier, explicitly specify a PATHPATTERN with meaningful names when you create the foreign table. For example, to match the path names selected in the river flow example, use ('$data/$siteno/$year/$month/$day'). PATHPATTERNs are useful for limiting results, instead of returning all the objects in an external object store.
The examples use a sample river flow data set. To use your own data, replace the table and column names, and authorization object. See Variable Substitutions for Examples for the credentials and location values for the sample data set.
- To run NOS-related commands, log on to the database as a user with the required privileges.
- If it does not exist, create the foreign table or ask your database administrator to create the foreign table called riverflow_json_path: See Filtering on the Payload Column of a Foreign Table.
-
Use path filtering to narrow down search results. To see the data for a site number on a particular date, query the path attributes:
SELECT TOP 2 payload.* FROM riverflow_json_path WHERE $PATH.$year = '2018' AND $PATH.$month = '07' AND $PATH.$day = '01.json' AND $PATH.$siteno = '09394500';
The $PATH.$day variable represents the actual object in the path segment name ( data / siteno / year / month / day). As such, it often has a file extension as part of the name, as shown in the example.
Result:
Payload.* ----------------------------------------------------------- ["09394500","2018-07-01 00:30","0.00","4.75","0.00","4.81"] ["09394500","2018-07-01 01:00","0.00","4.74","0.00","4.81"]
Note that the more specific you are with path filtering, the more selective are the results, potentially saving processing time and external storage access costs.