On 09/20/2012 03:34 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 09/20/2012 09:12 AM, Peter Eisentraut wrote:
It has been proposed that the plsh handler should strip the CRs before
execution. But I don't think that is a correct solution, because that
is user data which could be relevant. I
Andrew Dunstan writes:
> On 09/20/2012 09:12 AM, Peter Eisentraut wrote:
>> It has been proposed that the plsh handler should strip the CRs before
>> execution. But I don't think that is a correct solution, because that
>> is user data which could be relevant. It could be the case, for
>> exampl
On 09/20/2012 09:12 AM, Peter Eisentraut wrote:
On 9/20/12 2:01 AM, Heikki Linnakangas wrote:
Could you strip the CRs? Either at CREATE FUNCTION time, or when the
function is executed.
It has been proposed that the plsh handler should strip the CRs before
execution. But I don't think that is
On 9/20/12 2:01 AM, Heikki Linnakangas wrote:
> Could you strip the CRs? Either at CREATE FUNCTION time, or when the
> function is executed.
It has been proposed that the plsh handler should strip the CRs before
execution. But I don't think that is a correct solution, because that
is user data wh
On 20.09.2012 05:56, Peter Eisentraut wrote:
I have received a number of bug reports about plsh choking on
Windows-style line endings. The problem is that the user uses some
Windows-based tool or other to execute an SQL command line this:
CREATE FUNCTION foo() RETURNS something
LANGUAGE plsh
AS
I have received a number of bug reports about plsh choking on
Windows-style line endings. The problem is that the user uses some
Windows-based tool or other to execute an SQL command line this:
CREATE FUNCTION foo() RETURNS something
LANGUAGE plsh
AS $$
#!/bin/sh
do something
do something
$$;
w
