"Kevin Grittner" writes:
> Robert Haas wrote:
>> Can't you already do it this way:
>>
>> \set yadda `cat yadda_yadda.py`
>> CREATE FUNCTION yadda_yadda() returns text language plpythonu AS
>> :'yadda';
> Clever, but not pretty.
Yeah. So the question is whether this is useful enough to justif
Robert Haas wrote:
> Can't you already do it this way:
>
> \set yadda `cat yadda_yadda.py`
> CREATE FUNCTION yadda_yadda() returns text language plpythonu AS
> :'yadda';
OK, that works. It sure ain't pretty, though.
Clever, but not pretty.
-Kevin
--
Sent via pgsql-bugs mailing list (pg
On Tue, Feb 1, 2011 at 3:09 PM, Kevin Grittner
wrote:
> Steve White wrote:
>> On 1.02.11, Tom Lane wrote:
>>> "Kevin Grittner" writes:
Maybe some option for the \i command? \iq (for input quoted)
with automatic $$ quoting around what is read?
>>>
That way you could do something
Steve White wrote:
> On 1.02.11, Tom Lane wrote:
>> "Kevin Grittner" writes:
>>> Maybe some option for the \i command? \iq (for input quoted)
>>> with automatic $$ quoting around what is read?
>>
>>> That way you could do something like:
>>
>>> CREATE FUNCTION yadda_yadda() returns text langu
Steve White wrote:
> I said that the script interpreter might do this...
The script interpreter runs on the server.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Hi Tom,
I already agreed to Kevin's proposed syntax, and it is better than
my suggestion, but mine isn't quite as crazy as you make out.
On 1.02.11, Tom Lane wrote:
> Steve White writes:
> > Try this instead:
>
> >
> > CREATE OR REPLACE FUNCTION
Hi guys,
On 1.02.11, Tom Lane wrote:
> "Kevin Grittner" writes:
> > Maybe some option for the \i command? \iq (for input quoted) with
> > automatic $$ quoting around what is read?
>
> > That way you could do something like:
>
> > CREATE FUNCTION yadda_yadda() returns text language plpython
"Kevin Grittner" writes:
> Maybe some option for the \i command? \iq (for input quoted) with
> automatic $$ quoting around what is read?
> That way you could do something like:
> CREATE FUNCTION yadda_yadda() returns text language plpythonu as
> \iq yadda_yadda.py
> ;
Just got this --- looks
Steve White writes:
> Try this instead:
>
> CREATE OR REPLACE FUNCTION
> myfunc( ... )
> RETURNS VOID AS '#PGSQL_IMPORT filename' LANGUAGE PLPYTHONU;
>
I think having psql decide that string
"Kevin Grittner" writes:
> Tom Lane wrote:
>> The usual procedure is to put the whole CREATE FUNCTION statement
>> into a file, which you can then send with \i. I'm not quite
>> seeing the point of having just the body in a file? It's not like
>> the body is typically useful to run as standalon
Tom Lane wrote:
> The usual procedure is to put the whole CREATE FUNCTION statement
> into a file, which you can then send with \i. I'm not quite
> seeing the point of having just the body in a file? It's not like
> the body is typically useful to run as standalone code.
The OP mentioned tex
"Kevin Grittner" writes:
> It seems to me that something which let you pull the body of a
> script file into the statement on the *client* side of the
> connection, before sending the CREATE FUNCTION statement to the
> server would not only be a lot more secure (you could only read
> files that th
On 01/02/2011 6:50 PM, Steve White wrote:
Hi again, all,
OK I think I now know what the misunderstanding is.
[Please don't top-post. Rearranged for clarity.]
Steve White wrote:
On 1.02.11, Tom Lane wrote:
Steve White writes:
It would be really nice to have a way to load script (especia
Steve White wrote:
> I *DO NOT MEAN* that a query should run about grabbing files off
> the server, or wherever.
>
> I meant something like the replacement that happens with the \i
> command in loading SQL, and under similar circumstances, except
> that somehow non-SQL code is loadad in a funct
Hi again,
Now that I know what got you all riled, I can propose something that
might be more satisfactory. See below.
On 1.02.11, Steve White wrote:
> Hi again, all,
>
> OK I think I now know what the misunderstanding is.
>
> > [Please don't top-post. Rearranged for clarity.]
> >
> > Steve
Steve White wrote:
> On 1.02.11, Kevin Grittner wrote:
>> Steve White wrote:
>>> Isn't the \i command a similar security hole?
>>
>> That is run by a client program on a client machine.
>
> Sorry I don't understand this remark.
The CREATE FUNCTION statement is parsed and executed on the
Hi again, all,
OK I think I now know what the misunderstanding is.
> [Please don't top-post. Rearranged for clarity.]
>
> Steve White wrote:
> > On 1.02.11, Tom Lane wrote:
> >> Steve White writes:
> >>> It would be really nice to have a way to load script (especially
> >>> Python and Perl)
"Alexandre" writes:
> SELECT * FROM
> xpath_table('sequencia',
> 'registro',
> 'auditoria_anterior',
> 'name(/ROOT/CLIENTES/*)|/ROOT/CLIENTES/*',
> 'sequencia = 1')
> AS t(sequencia integer, coluna text, valor text)
> --Incorrect result-
Steve White wrote:
> Hi Kevin,
>
> On 1.02.11, Kevin Grittner wrote:
> > [Please don't top-post. Rearranged for clarity.]
> >
> As you like.
>
> > Steve White wrote:
> > > On 1.02.11, Tom Lane wrote:
> > >> Steve White writes:
> > >>> It would be really nice to have a way to load script (e
Hi Kevin,
On 1.02.11, Kevin Grittner wrote:
> [Please don't top-post. Rearranged for clarity.]
>
As you like.
> Steve White wrote:
> > On 1.02.11, Tom Lane wrote:
> >> Steve White writes:
> >>> It would be really nice to have a way to load script (especially
> >>> Python and Perl) from a s
Hi Pavel,
On 1.02.11, Pavel Stehule wrote:
> Hello
>
> 2011/2/1 Steve White :
> > Hi Tom,
> >
> > This seems like a detail that is beside the point I'm making.
> > But security is important, so let's think about it.
> >
> > PostgreSQL has an \i command, which loads the text from any readable fil
[Please don't top-post. Rearranged for clarity.]
Steve White wrote:
> On 1.02.11, Tom Lane wrote:
>> Steve White writes:
>>> It would be really nice to have a way to load script (especially
>>> Python and Perl) from a separate file into a function body.
>>
>> This seems like a security hole,
Hello
2011/2/1 Steve White :
> Hi Tom,
>
> This seems like a detail that is beside the point I'm making.
> But security is important, so let's think about it.
>
> PostgreSQL has an \i command, which loads the text from any readable file
> interpretes and executes it as further PostgreSQL commands.
Hi Tom,
This seems like a detail that is beside the point I'm making.
But security is important, so let's think about it.
PostgreSQL has an \i command, which loads the text from any readable file
interpretes and executes it as further PostgreSQL commands. I'm proposing
a similar mechanism that w
writes:
> I noticed that when pg_dump saves SQL code for a table with inheritance, it
> does not save any information about inherited columns. This is fine when
> inherited columns do not undergo any modification, but when they do, that
> information is lost.
> Example:
> create table parent
The following bug has been logged online:
Bug reference: 5859
Logged by: Alexandre
Email address: ultr...@gmail.com
PostgreSQL version: 8.4.7
Operating system: Windows 7
Description:XML result in line and column
Details:
The name of the xml tag is not being updated,
Steve White writes:
> It would be really nice to have a way to load script (especially Python
> and Perl) from a separate file into a function body.
This seems like a security hole, ie, you could use it to read any file
the backend has access to.
regards, tom lane
--
Se
Hi,
This was discussed on pgsql-general 28 Jan 2011.
It would be advantageous to have a portable, simple means of including
a module from the distribution contrib/ directory.
One idea would be some kind of variable expansion with the \i command:
\i $libdir/contrib/module.sql
Another woul
Hi
I asked on pgsql-general 31 Jan 2011 if there were a way to do this, and got
no response, so let's make it a feature request.
It would be really nice to have a way to load script (especially Python
and Perl) from a separate file into a function body. Some advantages would
be: to run a code ch
Hello,
I noticed that when pg_dump saves SQL code for a table with inheritance, it
does not save any information about inherited columns. This is fine when
inherited columns do not undergo any modification, but when they do, that
information is lost.
Example:
create table parent (id integer n
30 matches
Mail list logo
