I know the Information Schema is a SQL standard, but it's somewhat lacking.
I was trying to write a web page that showed a db table,it's columns and
foreign keys.
All went well and I was able to get this tool working great using the
information_schema, problem is that some of the information_sche
r d writes:
> My Database C1 definition:
> CREATE DATABASE "C1" ...
>TABLESPACE = "C1"
> After these two statements, tablespace C1 should be the default tablespace
> for storing all objects in database C1, meaning that when I do not specify
> a tablespace, objects are stored there. Right
Hi,
I'll first explain how it is now and then I'll explain how I think it
should behave :-)
I have Postgresql 9.1.4 64bit Linux
- The default tablespace at install is "pg_default" which is (here)
somewhere in /var/lib/...
- The parameter "default_tablespace" in *postgresql.conf* is commented out
On 2011-02-02, Steve White wrote:
> Hi, Robert,
>
> I made a file 'yadda_yadda.py' containing only the line:
> print 'hello world'
>
>
> d=# \set yadda `cat yadda_yadda.py`
> d=# \echo :yadda
> print 'hello world'
>==
On 2011-02-01, Steve White wrote:
> 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 bo
2011/2/2 Tom Lane :
> Pavel Stehule writes:
>> probably you need a third form of expansion - not implemented yet
>> ":$$var$$
>
> Seems quite useless. A string literal is a string literal.
>
I don't propose this form now. I saying so this form can be usefull for Steve.
It appends a started and
Pavel Stehule writes:
> probably you need a third form of expansion - not implemented yet
> ":$$var$$
Seems quite useless. A string literal is a string literal.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your su
Steve White writes:
> But the :'yadda'; produces an error--it seems the variable yadda isn't
> expanded in the presence of the quotes.
Apparently you're using a pre-9.0 psql.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make chang
Hello
probably you need a third form of expansion - not implemented yet
":$$var$$
escaping :'xxx' is designed for SQL language, not for Python :(
Regards
Pavel
2011/2/2 Steve White :
> Hi, Robert,
>
> On 1.02.11, Robert Haas wrote:
>>
>> Can't you already do it this way:
>>
>> \set yadda `ca
Hi, Robert,
On 1.02.11, 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';
>
> I guess it probably won't work on Windows...
>
This would also satisfy my immediate needs...
"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)
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
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
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
"Carl Holliday" writes:
> I need to be able to put pwds in the command line to facilitate
> non-supervised backups etc
We intentionally do not allow passwords on the command line, because
putting them there is a huge security hole. Use a ~/.pgpass file
instead. See
http://www.postgresql.org/doc
Afternoon
the 8.4 pg_dump seems to work fine and as documented.
I need to be able to put pwds in the command line to facilitate
non-supervised backups etc
I tried the following command line but, understandably, it refuses to
cooperate:
pg_dump.exe -h localhost -p 5432 -U postgres -W tstpwd1 -t
Robert Haas writes:
> On Mon, Mar 15, 2010 at 3:04 PM, Gregg Lind wrote:
>> As per http://osdir.com/ml/pgsql-hackers/2010-03/msg00331.html, I would
>> certainly find it helpful is count(distinct(myfield)) wasn't a full index
>> scan.
> We should maybe add this to our Todo file, if it's not there
On Mon, Mar 15, 2010 at 3:04 PM, Gregg Lind wrote:
> As per http://osdir.com/ml/pgsql-hackers/2010-03/msg00331.html, I would
> certainly find it helpful is count(distinct(myfield)) wasn't a full index
> scan.
We should maybe add this to our Todo file, if it's not there already
(I don't see it on
As per http://osdir.com/ml/pgsql-hackers/2010-03/msg00331.html, I would
certainly find it helpful is count(distinct(myfield)) wasn't a full index
scan.
Gregg Lind
Pavel
>
> - Original Message - From: "Pavel Stehule" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc:
> Sent: Monday, May 05, 2008 8:10 PM
> Subject: Re: [BUGS] Feature request
>
>
>> Hello
>>
>> 2008/5/5 <[EMAIL PROTECTED]
PM
Subject: Re: [BUGS] Feature request
Hello
2008/5/5 <[EMAIL PROTECTED]>:
So why I can do:
insert into (id) values ( default )
and can not do in my trigger:
new.id = default
Why?
it's not possible - because you cannot mix PL/pgSQL statement
(assignment) and SQL stetement.
Hello
2008/5/5 <[EMAIL PROTECTED]>:
> So why I can do:
> insert into (id) values ( default )
> and can not do in my trigger:
> new.id = default
> Why?
it's not possible - because you cannot mix PL/pgSQL statement
(assignment) and SQL stetement.
syntax of assignment
:
variable := expression
exp
So why I can do:
insert into (id) values ( default )
and can not do in my trigger:
new.id = default
Why?
Subject nearly says it all. Could we add it to the TODO list to have
per table statistics? I have a table here that requires a stats target
of 1000 in order for it to project values correctly (believe me, tried
everything in increments of 50 from 10 on up, it needs 1000). The
problem being t
hi all
it would be good to have RETURNING clause in INSERT,UPDATE,DELETE queries.
similar to Oracle's one but more clever.
Oracle's "RETURNING" is just a disguised independant SELECT wich is not
wanted.
i found "RETURNING" usable if it returns just inserted or just deleted record.
e.g. i have som
46 matches
Mail list logo
