| From: | PFC <lists(at)boutiquenumerique(dot)com> |
|---|---|
| To: | "Michael Fuhr" <mike(at)fuhr(dot)org> |
| Cc: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>, "Alvaro Herrera" <alvherre(at)dcc(dot)uchile(dot)cl>, "Bo Lorentsen" <bl(at)netgroup(dot)dk>, "pgsql-general postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: OID Usage |
| Date: | 2005-01-15 19:20:04 |
| Message-ID: | opsknrzqgnth1vuj@musicbox |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Uh, sorry, my mistake !
I had put SERIAL instead of an INTEGER in the table definition !
You just removed a bug in my schema ;)
> On Sat, Jan 15, 2005 at 09:02:12AM +0100, PFC wrote:
>>
>> As a sidenote, I have a table with a primary key which is not a
>> sequence, and this query displays the non-existing sequence name. It
>> would
>> be easy to check if the sequence exists (yet another join !), only
>> display
>> sequences that exist ;)...
>
> Hmmm...that's odd, since the query gets the sequence name through
> a series of inner joins that go back go pg_class -- if the sequence
> doesn't exist then where is the name coming from? I did notice
> that the query should add "AND attisdropped IS FALSE" to the join
> with pg_attribute, but I don't see how that would affect this case.
>
> Can you spot where the mistake is? What does "\d tablename" show
> for the table in question?
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Berteun Damman | 2005-01-15 19:40:34 | Re: Pgsql taking a *lot* of CPU time (unkillable). |
| Previous Message | Michael Fuhr | 2005-01-15 18:32:41 | Re: Index optimization ? |