> On 2 Sep 2022, at 11:19, Daniel Gustafsson wrote:
> The patch missed to update the corresponding list for TG_ event trigger vars,
> fixed in the attached.
I took another look at this, and pushed it with a few small tweaks. Thanks!
--
Daniel Gustafsson https://vmware.com/
> On 1 Sep 2022, at 15:07, Christoph Berg wrote:
> Re: Dagfinn Ilmari Mannsåker
>>> I also shortened some "name of table" to just "table". Since the data
>>> type is "name", it's clear what "table" means.
>>
>> I think it reads better with the definite article and initial capital,
>> e.g. "The t
Re: Dagfinn Ilmari Mannsåker
> > Actually, just omitting the whole prefix works best.
> >
> > TG_WHEN (text)
> >
> > BEFORE, AFTER, or INSTEAD OF, depending on the trigger's definition.
>
> The attached patch does not reflect this, did you attach an old version?
Forgot to git commit before ex
Christoph Berg writes:
> Re: To Daniel Gustafsson
>> "string containing" is again pretty boilerplatish, how about just
>> "contains"?
>
> Actually, just omitting the whole prefix works best.
>
> TG_WHEN (text)
>
> BEFORE, AFTER, or INSTEAD OF, depending on the trigger's definition.
The attac
Re: To Daniel Gustafsson
> "string containing" is again pretty boilerplatish, how about just
> "contains"?
Actually, just omitting the whole prefix works best.
TG_WHEN (text)
BEFORE, AFTER, or INSTEAD OF, depending on the trigger's definition.
I also shortened some "name of table" to just "
Re: Daniel Gustafsson
> This, and the other string variables, now reads a bit strange IMO:
>
> - Data type text; a string of
> + string
> INSERT, UPDATE,
> DELETE, or TRUNCATE
>
> Wouldn't it be better with "string containing INSERT.." or something
> similar?
Right, t
> On 31 Aug 2022, at 13:55, Christoph Berg wrote:
>
> Re: To Peter Eisentraut
>> The new version of the patch just moves up the data types, and removes
>> the extra clutter from the beginnings of each description:
>
> The last version had the brackets in TG_ARGV[] (text[]) duplicated.
This, and
Re: To Peter Eisentraut
> The new version of the patch just moves up the data types, and removes
> the extra clutter from the beginnings of each description:
The last version had the brackets in TG_ARGV[] (text[]) duplicated.
Christoph
>From 1355794d56919a015bd1528f62428beaab0a681b Mon Sep 17 00:
Re: Peter Eisentraut
> I find the new version even harder to read. The catalog_table_entry stuff
> doesn't really make sense here, since what you have before is already a
> definition list, and afterwards you have the same, just marked up
> "incorrectly".
Fair enough. For comparison, this is what
> On 31 Aug 2022, at 11:35, Peter Eisentraut
> wrote:
>
> On 30.08.22 15:16, Christoph Berg wrote:
>> I found the list of TG_ variables on
>> https://www.postgresql.org/docs/current/plpgsql-trigger.html#PLPGSQL-DML-TRIGGER
>> hard to read for several reasons: too much whitespace, all the lines
>
On 30.08.22 15:16, Christoph Berg wrote:
I found the list of TG_ variables on
https://www.postgresql.org/docs/current/plpgsql-trigger.html#PLPGSQL-DML-TRIGGER
hard to read for several reasons: too much whitespace, all the lines
start with "Data type", and even after that, the actual content is
hi
Hi,
I found the list of TG_ variables on
https://www.postgresql.org/docs/current/plpgsql-trigger.html#PLPGSQL-DML-TRIGGER
hard to read for several reasons: too much whitespace, all the lines
start with "Data type", and even after that, the actual content is
hiding behind some extra "variable that.
12 matches
Mail list logo
