<div class="moz-cite-prefix">On 03/05/13 04:52, David Fetter wrote:<br /></div><blockquote
cite="mid:20130502165238.GB12887@fetter.org"type="cite"><pre wrap="">On Thu, May 02, 2013 at 06:28:53PM +0200, Andres
Freundwrote:
</pre><blockquote type="cite"><pre wrap="">On 2013-05-02 12:23:19 -0400, Tom Lane wrote:
</pre><blockquote type="cite"><pre wrap="">Marko Tiikkaja <a class="moz-txt-link-rfc2396E"
href="mailto:marko@joh.to"><marko@joh.to></a>writes:
</pre><blockquote type="cite"><pre wrap="">What I'm more interested in is: how can we make this feature work in
PL/PgSQL where OLD means something different?
</pre></blockquote><pre wrap="">
That's a really good point: if you follow this approach then you're
creating fundamental conflicts for use of the feature in trigger
functions or rules, which will necessarily have conflicting uses of
those names. Yeah, we could define scoping rules such that there's
an unambiguous interpretation, but then the user is just out of luck
if he wants to reference the other definition. (This problem is
probably actually worse if you implement with reserved words rather
than aliases.)
I'm thinking it would be better to invent some other notation for access
to old-row values.
</pre></blockquote><pre wrap="">
prior/after? Both are unreserved keywords atm and it seems far less
likely to have conflicts than new/old.
</pre></blockquote><pre wrap="">
BEFORE/AFTER seems more logical to me. Yes, those words both have
meaning in, for example, a trigger definition, but they're clearly
separable by context.
Yay, bike-shedding!
Cheers,
David.
</pre></blockquote><font size="-1">I prefer 'PRIOR & 'AFTER'</font> as the both have the same length <br /> - but
perhapsthat is just me! :-)<br /><br /><br /> Cheers,<br /> Gavin<br /><br /><br /><br />
