| 3 | | namespace (create or usage) and there's a 'search_path' variable that |
| 4 | | lists out the schemas to be searched for when no specific schema is |
| 5 | | given. It's alot like Oracle accounts except you don't actually have to |
| 6 | | have an account to have a schema, which is *very* nice. Generally each |
| 7 | | *real* user has his/her own schema though, except for role accounts |
| 8 | | which just use other schemas. Schemas are tracked in Postgres via the |
| 9 | | pg_namespace system table. |
| | 2 | namespace (create or usage) and there's a 'search_path' variable that lists out the schemas to be searched for when no specific schema is given. |
| | 3 | |
| | 4 | It's a lot like Oracle accounts except you don't actually have to |
| | 5 | have an account to have a schema, which is *very* nice. Generally each '''real''' user has his/her own schema though, except for role accounts which just use other schemas. |
| | 6 | |
| | 7 | Schemas are tracked in Postgres via the pg_namespace system table. |
| 13 | | Now, there exists a 'sfrost' schema, so that's what I'm looking at when |
| 14 | | I first log in and do \d. I *only* see things in the 'sfrost' schema |
| 15 | | and the 'public' schema though. Now, say there's another schema called |
| 16 | | 'lerg', I can reference that schema directly by saying: |
| | 12 | Now, there exists a 'sfrost' schema, so that's what I'm looking at when I first log in and do '''\d'''. I '''only''' see things in the 'sfrost' schema and the 'public' schema though. Now, say there's another schema called 'lerg', I can reference that schema directly by saying: |
| 23 | | Now, what happened when I ran ogr2ogr was that it dumped the new tables |
| 24 | | into 'sfrost', my default schema. What I'd like to have happen is for |
| 25 | | the tables to be loaded into their own schema. I wouldn't expect |
| 26 | | ogr2ogr to actually create the schema, that's generally an operation |
| 27 | | reserved for the database superuser. What I'd like is the ability to |
| 28 | | tell ogr2ogr what schema to use. Having support directly in |
| 29 | | ogr2ogr would mean that you could then specify a list of *schemas* to |
| 30 | | search for layers, instead of tables, which would make things easier |
| 31 | | both from an ogr2ogr point of view and from a user's point of view, I'd |
| 32 | | think. Additionally, it doesn't appear possible to specify a schema to use in |
| 33 | | the PGconnectdb string. |
| | 20 | Now, what happened when I ran ogr2ogr was that it dumped the new tables into 'sfrost', my default schema. What I'd like to have happen is for the tables to be loaded into their own schema. I wouldn't expect ogr2ogr to actually create the schema, that's generally an operation reserved for the database superuser. |
| 35 | | From what I can tell ogr2ogr just needs to issue a 'set schema_path to %s' |
| 36 | | command where the %s is provided on the command-line to get basic schema support. |
| 37 | | }}} |
| | 22 | What I'd like is the ability to tell ogr2ogr what schema to use. Having support directly in ogr2ogr would mean that you could then specify a list of '''schemas''' to search for layers, instead of tables, which would make things easier both from an ogr2ogr point of view and from a user's point of view, I'd think. |
| | 23 | |
| | 24 | Additionally, it doesn't appear possible to specify a schema to use in the '''PGconnectdb''' string. |
| | 25 | |
| | 26 | From what I can tell ogr2ogr just needs to issue a 'set schema_path to %s' command where the %s is provided on the command-line to get basic schema support. |
