From: | Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | Arnaud Lesauvage <arnaud(dot)listes(at)codata(dot)eu> |
Cc: | pgsql-odbc(at)postgresql(dot)org |
Subject: | Re: 'default nextval()' loses schema-qualification in dump ? |
Date: | 2010-07-09 03:31:03 |
Message-ID: | 4C3697F7.1060600@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-odbc |
Arnaud Lesauvage wrote:
> Le 7/07/2010 9:41, Richard Huxton a écrit :
>> On 07/07/10 07:47, Arnaud Lesauvage wrote:
>>> Le 6/07/2010 17:17, Tom Lane a écrit :
>>>> Arnaud Lesauvage<arnaud(dot)listes(at)codata(dot)eu> writes:
>>>>> As you have understood, I am not very savvy about postgresql's
>>>>> internals, but from what you say my guess is that the problem is
>>>>> int the
>>>>> psqlODBC is getting the default value of the sequence ?
>>
>>> [9.125]conn=095C4198, query='select n.nspname, c.relname, a.attname,
>>> a.atttypid, t.typname, a.attnum, a.attlen, a.atttypmod, a.attnotnull,
>>> c.relhasrules, c.relkind, c.oid, d.adsrc, case t.typtype when 'd' then
>>> t.typbasetype else 0 end, t.typtypmod from (((pg_catalog.pg_class c
>>> inner join pg_catalog.pg_namespace n on n.oid = c.relnamespace and
>>> c.relname = E'mytable' and n.nspname = E'myschema') inner join
>>> pg_catalog.pg_attribute a on (not a.attisdropped) and a.attnum> 0 and
>>> a.attrelid = c.oid) inner join pg_catalog.pg_type t on t.oid =
>>> a.atttypid) left outer join pg_attrdef d on a.atthasdef and d.adrelid =
>>> a.attrelid and d.adnum = a.attnum order by n.nspname, c.relname,
>>> attnum'
>>
>> This is psqlODBC getting the sequence name (if you run this query it's
>> the adsrc column). If I remember correctly, that's supposed to be the
>> human-readable version of an expression and preserved *as entered by the
>> user* (or pg_restore in your case).
>>
>> If you start psql with the "-E" option and do \d myschema.mytable you'll
>> be able to see how it gets the sequence-name. About half-way down the
>> list of queries it runs you'll see a reference to pg_get_expr(...) -
>> that turns an internal representation into a useful usable one.
>>
>> I don't know why psqlODBC isn't using that. The function has been around
>> for a while. Hmm - it's present back in 7.4 although it's not used in \d
>> - that does reference adsrc directly.
>>
>> Just grabbed the source download for the latest version and it still
>> looks like it's using adsrc (I just searched for that and pg_get_expr).
>> There should probably be a change in info.c around line 2091 to add a
>> check for a recent version of PG (8+) and use pg_get_expr. Check on the
>> odbc mailing-list - there may be an updated version available for you to
>> test.
>>
>
>
> I haven't found a version more recent than the one I am using.
> Is this thread enough for a bug report, or should a new one be opened ?
>
> I don't think I know enough of either psqlODBC's internals to explain
> the problem to the developers, and I am not sure this thread will get
> their attention.
Could you please try the drivers on testing for 8.4.0201 at
http://www.geocities.jp/inocchichichi/psqlodbc/index.html
?
regards,
Hiroshi Inoue
From | Date | Subject | |
---|---|---|---|
Next Message | tamanna madaan | 2010-07-09 04:56:43 | "attempted to lock invisible tuple" error while update |
Previous Message | Craig Ringer | 2010-07-09 03:08:44 | Re: weird empty return from select problem; periodically get no data returned - could it be a network issue? |
From | Date | Subject | |
---|---|---|---|
Next Message | Arnaud Lesauvage | 2010-07-09 07:40:53 | Re: 'default nextval()' loses schema-qualification in dump ? |
Previous Message | Hiroshi Inoue | 2010-07-08 21:48:17 | Re: Mysteriously slow query, and side-by-side installation of 8.1 and 8.4 ODBC drivers |