Re: Foreign keys for non-default datatypes, redux

From: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
To: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
Subject: Re: Foreign keys for non-default datatypes, redux
Date: 2007-02-13 10:46:36
Message-ID: 45D1970C.8030700@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Treat wrote:
> On Saturday 10 February 2007 13:59, Tom Lane wrote:
>> Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
>>> I'd say we probably want to keep the tgargs info for at least a version
>>> or two after changing the implementation. Getting rid of using the args
>>> info sounds like a good idea.
>> We whack the catalogs around in incompatible ways in every release. I'm
>> willing to keep filling tgargs if someone can point to a real use-case,
>> but not just because there might be code out there somewhere using it.
>>
>
> I'm pretty sure we use tgargs in phppgadmin, though exactly why escapes me...
> I am thinking it would be to display a triggers arguments? Assuming we can
> still get all the same information one way or another I suppose we can update
> our code, though right now that code is pretty well intermixed with the
> normal function code iirc (I don't think it has been updated at all in the
> 8.x series, so my memory is pretty fuzzy on this), so if I could avoid
> changing it I would...

As far as I understood the proposal, tgargs wouldn't go away, it would just not
be populated for RI triggers. So as long as pgadmin3 doesn't use tgargs to get
information about constraints, pgadmin would be fine I believe...

greetings, Florian Pflug

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2007-02-13 13:49:00 Re: Variable length varlena headers redux
Previous Message Heikki Linnakangas 2007-02-13 09:21:35 Re: HOT for PostgreSQL 8.3