On Thu, Feb 6, 2014 at 10:27 AM, k...@rice.edu wrote:
>> Thanks for the feedback.
>>
>> Our problem is that an application decides the name of the columns in
>> the tables and "XDB replication" from EnterpriseDB decides the triggers.
>> We have no control over the code :-(
>>
>
> It sounds like a
On Thu, Feb 06, 2014 at 04:21:41PM +0100, Rafael Martinez Guerrero wrote:
> On Thu, 2014-02-06 at 07:11 -0800, Adrian Klaver wrote:
> > On 02/06/2014 06:35 AM, Rafael Martinez Guerrero wrote:
>
> > > We think the behavior should be consistent, either it is allow to use
> > > them or not, but not l
On Thu, 2014-02-06 at 07:11 -0800, Adrian Klaver wrote:
> On 02/06/2014 06:35 AM, Rafael Martinez Guerrero wrote:
> > We think the behavior should be consistent, either it is allow to use
> > them or not, but not like it is today.
> >
>
> " As a general rule, if you get spurious parser errors for
Rafael Martinez Guerrero writes:
> The problem is that pl/pgsql does not accept open and close as column
> names when used in the NEW record in a trigger function.
Yup. Those words (and other words that can start a plpgsql statement)
are reserved so far as plpgsql is concerned.
> This page:
> h
On 02/06/2014 06:35 AM, Rafael Martinez Guerrero wrote:
Hello
One of our users is having a problem with a trigger in a system running
postgresql 9.3.
The problem is that pl/pgsql does not accept open and close as column
names when used in the NEW record in a trigger function.
This page:
http:/
Hello
One of our users is having a problem with a trigger in a system running
postgresql 9.3.
The problem is that pl/pgsql does not accept open and close as column
names when used in the NEW record in a trigger function.
This page:
http://www.postgresql.org/docs/9.3/static/sql-keywords-appendix.