Thread: Small FK patch to deal with tables without oids

    Tables without oids wouldn't be able to be
used inside fk constraints, since some of the checks
in the trigger did a SELECT oid.  Since the oid wasn't
actually used, I changed this to SELECT 1.  My test
case with non-oid tables now works and fk regression
appears to run fine on my machine.

Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
>     Tables without oids wouldn't be able to be
> used inside fk constraints, since some of the checks
> in the trigger did a SELECT oid.  Since the oid wasn't
> actually used, I changed this to SELECT 1.

Can't believe I missed that while looking for OID dependencies :-(
Good catch!

            regards, tom lane

Tom, I assume you want this applied?

---------------------------------------------------------------------------

> Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
> >     Tables without oids wouldn't be able to be
> > used inside fk constraints, since some of the checks
> > in the trigger did a SELECT oid.  Since the oid wasn't
> > actually used, I changed this to SELECT 1.
>
> Can't believe I missed that while looking for OID dependencies :-(
> Good catch!
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom, I assume you want this applied?

Please.

            regards, tom lane


> ---------------------------------------------------------------------------

>> Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
> Tables without oids wouldn't be able to be
> used inside fk constraints, since some of the checks
> in the trigger did a SELECT oid.  Since the oid wasn't
> actually used, I changed this to SELECT 1.
>>
>> Can't believe I missed that while looking for OID dependencies :-(
>> Good catch!
>>
>> regards, tom lane
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>>

> --
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom, I assume you want this applied?
>
> Please.

Done.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Patch applied.  Thanks.

---------------------------------------------------------------------------


>
>     Tables without oids wouldn't be able to be
> used inside fk constraints, since some of the checks
> in the trigger did a SELECT oid.  Since the oid wasn't
> actually used, I changed this to SELECT 1.  My test
> case with non-oid tables now works and fk regression
> appears to run fine on my machine.

Content-Description:

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026