From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Arnaud Lesauvage <arnaud(dot)listes(at)codata(dot)eu> |
Cc: | pgsql-odbc(at)postgresql(dot)org, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: 'default nextval()' loses schema-qualification in dump ? |
Date: | 2010-07-06 14:22:14 |
Message-ID: | 27289.1278426134@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-odbc |
Arnaud Lesauvage <arnaud(dot)listes(at)codata(dot)eu> writes:
> After some research, we found in psqlODBC's log that before the restore
> psqlODBC was getting the sequence's nextval with a schema qualified
> call, and after the restore the call was not schema qualified.
> I checked in pg_attrdef before and after the dump/restore, and indeed
> the "default nextval()" on this problematic table loses it's schema
> qualification in the process.
This is a pretty inadequate description of your problem. Let's see the
exact SQL you are dealing with.
Note that if the argument of nextval is a plain regclass constant, like
nextval('seq'::regclass)
then the constant is in fact a reference to a specific sequence.
Whether it's displayed with a schema name depends on whether that
sequence is visible in your search_path.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | ChronicDB Community Team | 2010-07-06 14:51:24 | Feedback on live schema changes and updates for PostgreSQL |
Previous Message | Alban Hertroys | 2010-07-06 14:09:26 | Re: Rules in views, how to? |
From | Date | Subject | |
---|---|---|---|
Next Message | Arnaud Lesauvage | 2010-07-06 15:02:43 | Re: 'default nextval()' loses schema-qualification in dump ? |
Previous Message | Arnaud Lesauvage | 2010-07-06 10:02:30 | 'default nextval()' loses schema-qualification in dump ? |