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
Using `gtfs-via-postgres`, you can import more than one dataset into a single PostgreSQL database by importing them into separate [schemas](https://www.postgresql.org/docs/14/ddl-schemas.html). You can then run queries combine or compare data from them.
We can now do queries across both datasets, for example finding the geographically furthest 2 stops:
22
-
23
-
```sql
24
-
-- warning: takes a long time to compute!
25
-
SELECT
26
-
paris.stop_idAS paris_stop_id,
27
-
berlin.stop_idAS berlin_stop_id
28
-
FROM
29
-
paris.stops paris,
30
-
berlin.stops berlin
31
-
ORDER BYparis.stop_loc<->berlin.stop_locDESC
32
-
LIMIT100
33
-
```
34
-
35
-
*Note:* During an import, a function `public.gtfs_via_postgres_import_version()` gets created that returns `gtfs-via-postgres`'s version. If that function already exists (because it has been created by a previous import), its return value is compared to `gtfs-via-postgres`'s version, and if these two versions are not equal, the second import will fail. This ensures that multiple imports into the same database can only be made using the exact same `gtfs-via-postgres` version.
3
+
Using `gtfs-via-postgres`, it is currently *not possible* to import more than one dataset into a single PostgreSQL database.
${opt.schema!=='public' ? `CREATE SCHEMA IF NOT EXISTS "${opt.schema}";` : ''}
146
144
BEGIN;
147
145
148
-
-- gtfs-via-postgres supports importing >1 GTFS datasets into 1 DB, each dataset within its own schema. See https://github.com/public-transport/gtfs-via-postgres/issues/51 for more information.
149
-
-- Because almost all helper utilities (enums, functions, etc.) are schema-specific, they get imported more than once. In order to prevent subtle bugs due to incompatibilities among two schemas imported by different gtfs-via-postgres versions, we mock a "mutex" here by checking for public.gtfs_via_postgres_import_version()'s return value.
150
-
151
-
-- todo: this can be done more elegantly: just a "DO" block, "ASSERT" that the version matches, create gtfs_via_postgres_import_version() in the "EXCEPTION" block
152
-
CREATE FUNCTION pg_temp.get_gtfs_via_postgres_import_version()
153
-
RETURNS TEXT
154
-
AS $$
155
-
DECLARE
156
-
res TEXT;
157
-
BEGIN
158
-
SELECT public.gtfs_via_postgres_import_version() INTO res;
159
-
RETURN res;
160
-
EXCEPTION
161
-
WHEN undefined_function THEN
162
-
-- do nothing, silence error
163
-
RETURN NULL;
164
-
END;
165
-
$$
166
-
LANGUAGE plpgsql;
167
-
168
-
DO $$
169
-
BEGIN
170
-
IF EXISTS (
171
-
SELECT version
172
-
FROM (
173
-
SELECT pg_temp.get_gtfs_via_postgres_import_version() AS version
174
-
) t
175
-
WHERE version != '${pkg.version}'
176
-
) THEN
177
-
RAISE EXCEPTION 'existing GTFS data imported with an incompatible version of gtfs-via-postgres';
178
-
END IF;
179
-
END
180
-
$$
181
-
LANGUAGE plpgsql;
182
-
183
-
CREATE OR REPLACE FUNCTION public.gtfs_via_postgres_import_version()
CREATE TYPE "${opt.schema}".exact_times_v AS ENUM (
7
+
CREATE TYPE exact_times_v AS ENUM (
8
8
'frequency_based' -- 0 or empty - Frequency-based trips.
9
9
, 'schedule_based' -- 1 β Schedule-based trips with the exact same headway throughout the day. In this case the end_time value must be greater than the last desired trip start_time but less than the last desired trip start_time + headway_secs.
10
10
);
11
-
CREATE CAST ("${opt.schema}".exact_times_v AS text) WITH INOUT AS IMPLICIT;
11
+
CREATE CAST (exact_times_v AS text) WITH INOUT AS IMPLICIT;
12
12
13
-
CREATE TABLE "${opt.schema}".frequencies (
13
+
CREATE TABLE frequencies (
14
14
-- Used to implement arrivals_departures & connections. Filled after COPY-ing, see below.
0 commit comments