On Thu, Jun 15, 2017 at 1:56 PM, Tom Lane wrote:
> Jim Fulton writes:
> > I have an object database that's mirrored to a table with data in a JSONB
> > column. Data are organized into "communities". Community ids aren't
> > stored directly in content but can be found by recursively following
>
Jim Fulton writes:
> I have an object database that's mirrored to a table with data in a JSONB
> column. Data are organized into "communities". Community ids aren't
> stored directly in content but can be found by recursively following
> __parent__ properties. I want to be able to index content
On Thu, Jun 15, 2017 at 1:44 PM, Adrian Klaver
wrote:
> On 06/15/2017 10:23 AM, Jim Fulton wrote:
>
...
> I do not pretend to fully understand what the the triggers/functions are
> really doing,
but I did notice this:
>
> create or replace function populate_community_zoid_triggerf()
>
> ...
>
On 06/15/2017 10:23 AM, Jim Fulton wrote:
I have an object database that's mirrored to a table with data in a
JSONB column. Data are organized into "communities". Community ids
aren't stored directly in content but can be found by recursively
following __parent__ properties. I want to be able
From: "Jamie Deppeler" <[EMAIL PROTECTED]>
> Hi , i have designed a trigger function called test2(Integer)
the trigger function must be declared without arguments
http://scripts.postgresql.org/docs/7.4/static/triggers.html#TRIGGER-DEFINITI
ON
gnari
---(end of broad
That is probably because you created test2(INTEGER) and you're trying to
call test2(TEXT).
On Wed, Dec 01, 2004 at 11:22:41AM +1100, Jamie Deppeler wrote:
> Hi , i have designed a trigger function called test2(Integer)
>
> im trying to use it with a trigger but get errors that function cannot
>
On Thu, Dec 07, 2000 at 03:40:00PM -0600, some SMTP stream spewed forth:
> Ok, so I'm not sure why this is the way it is, but I figured out why the backend was
>failing every time I tried to change the data on the existing five tables. When I
>dropped the five unused tables, I assumed that the
Ok, so I'm not sure why this is the way it is,
but I figured out why the backend was failing every time I tried to change the
data on the existing five tables. When I dropped the five unused tables, I
assumed that the DROP function would also remove the foreign key constraint
triggers that
