Message-ID: <3F255B02.80607@openratings.com>
Date: Mon, 28 Jul 2003 13:18:58 -0400
From: Dmitry Tkach <dmitry@openratings.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Denis Zaitsev <zzz@anda.ru>, pgsql-sql@postgresql.org
Subject: Re: Very strange 'now' behaviour in nested triggers.
References: <20030726193947.B1636@natasha.ward.six>
	<9412.1059229904@sss.pgh.pa.us>
	<20030727020104.A19865@natasha.ward.six>
	<4629.1059320950@sss.pgh.pa.us> <3F2552BF.5060100@openratings.com>
	<15184.1059411161@sss.pgh.pa.us> <3F255813.1000401@openratings.com>
	<15800.1059412373@sss.pgh.pa.us>
In-Reply-To: <15800.1059412373@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

>Dmitry Tkach <dmitry@openratings.com> writes:
>  
>
>>Does it mean that the *application* (not the database) user would then 
>>have to know the exact specific way to represent the current time in his 
>>data entry form?
>>Such an application looks like (how do I say it politely?) not a very 
>>user-friendly one to me :-)
>>    
>>
>
>So?  "now()" is certainly not more user-friendly than "now". 
>
Nope... it isn't.
My point was that, if the app wanted to be user friendly, it would not 
attempt to take the input directly from user and stuff it into the sql - 
it would probably have some checkbox or drop-down list in the GUI form, 
that would indicate that the user wants the current time stamp, and use 
the the proper internal represntation in the generated sql...
In that case having to execute a function (now()) would not make it 
vulnerable to a sql injection...

> My point
>is that wherever you are making the decision that you want to input
>current time, there may be layers between you and the database that will
>only want to pass data-value strings and not function invocations.
>
>  
>
Yeah... I've actually found one after I sent that last message :-) - it 
does seem to come handy in COPY TABLE - although, in that case, I'd say 
it would be much more useful to make COPY TABLE understand the defined 
defaults on the table, just the way INSERT does ...

Dima