Re: [BUGS] Feature request: include script file into function body
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 body. Some advantages would > be: to run a code checker outside of Postgresql, and to make things easier > for source code colorizers. > > I have in mind syntax something like> > > CREATE OR REPLACE FUNCTION > myfunc( ... ) > RETURNS VOID FROM 'ScriptFile.py' LANGUAGE PLPYTHONU; > others have complained about the backend reading files maybe this coould be implemented in PSQL instead. (like \i and \copy are...) something like: \CREATE OR REPLACE FUNCTION myfunc( ... ) RETURNS VOID FROM 'ScriptFile.py' LANGUAGE PLPYTHONU psql would then need to slurp the file and quote the function body, but pq_escape_string_conn is presumably upto that task. on the other hand binary fuunctions (eg C) are read from files, but not directly by the backend, dlopen (or equivalent) is used instead. on the other hand, for symmetry I guess a form that matches yours is needed too, but, if using named files that will probably need database superuser permission (like the other named file functions do). Then ther could be an unpriviledged "from stdin" variant that psql could use to send the content (instead of quoting it and sending it in-line). ISTR C functions need superuser too. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Feature request: include script file into function body
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' > > But the :'yadda'; produces an error--it seems the variable yadda isn't > expanded in the presence of the quotes. yes, \set doesn't quote content \set yadda `sed -e "s/'/''/g" -e 's/\\//g' < yadda_yadda.py` CREATE FUNCTION yadda_yadda() returns text language plpythonu AS E:yadda; this is not much help for windows users though. BTW I found that sed command on the psql man page. -- ⚂⚃ 100% natural -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Re: Feature request: include script file into function body (better syntax)
On 2011-02-01, Steve White wrote: > 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 >> > myfunc( ... ) >> > RETURNS VOID AS '#PGSQL_IMPORT filename' LANGUAGE PLPYTHONU; >> > >> >> I think having psql decide that string literals mean something other >> than their face value is Right Out --- it would bite you on the rear >> just when you least expect it. > > Interesting idea... but why would psql make this decision? > Did somebody suggest that off-line? > > I said that the script interpreter might do this... if the interpreter does it you stop ordinary users from using it for security reasons, -- ⚂⚃ 100% natural -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5862: Postgres dumps core upon a connection attempt
As far as the configure options -- Originally, they were merely --with-perl and --with-python, but just to rule out problems there, I've since just been going with a straight compile (not additional options). I will get the backtrace, etc. within the next hour or so. Thanks! - Matt Quoting Craig Ringer : > On 03/02/11 11:11, Matt Zinicola wrote: > > OK, it doesn't seem to be a simple problem of linking to the wrong > library then. psql is linking to the correct libpq. initdb isn't linking > to anything much at all, but still crashes for no apparent reason. > Something else may be going on. Please supply the full command line you > used to "./configure" when compiling postgres. If you're not sure what > it was, you can find it in the top of "config.log" in your compile > directory. > > Is there any chance you can get us a backtrace of one of the crashing > programs? Try this: > > gdb --args psql > > Once it loads, it'll drop you to a > > (gdb) > > prompt. Enter "run" then press enter. > > (gdb) run > > Psql will then load for a while, crash, and drop you back to a (gdb) > prompt after printing out a message like: > > Program received signal SIGSEGV, Segmentation fault. > > Enter the "bt" command at the (gdb) prompt and press enter. > > (gdb) bt > > ... then copy and paste everything from "gdb --args psql" through to the > end of the output printed by "bt", put it on http://pastebin.com/ and > send a link to that in your reply email here. > > I've created a sample to give you the idea, by starting psql then > intentionally crashing it by sending it a manual SIGSEGV. See: > > http://pastebin.com/b8D9i2tb > > > -- > System & Network Administrator > POST Newspapers > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5856: pg_attribute.attinhcount is not correct.
On Mon, Jan 31, 2011 at 6:42 AM, Naoya Anzai
wrote:
> In PostgreSQL8.4.5, I found that the catalog pg_attribute.attinhcount is not
> correct.
>
> I executed the following queries.
>
> --
> create table "3_grandchild"();
> create table "2_child"();
> create table "1_parent"();
>
> alter table "3_grandchild" inherit "2_child";
> alter table "2_child" inherit "1_parent";
>
> alter table "3_grandchild" add column c1 text;
> alter table "2_child" add column c1 text;
> alter table "1_parent" add column c1 text;
>
> select c.relname,a.attname,a.attinhcount from pg_attribute a,pg_class c
> where a.attrelid=c.oid
> and relname in ('1_parent','2_child','3_grandchild')
> and attname not in('xmax','xmin','cmin','cmax','tableoid','ctid')
> order by relname;
>
> relname | attname | attinhcount
> --+-+-
> 1_parent | c1 | 0
> 2_child | c1 | 1
> 3_grandchild | c1 | 2
> (3 rows)
> --
>
> "3_grandchild"'s attinhcount should be 1.
I think this is a manifestation the same problem mentioned here:
http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=31b6fc06d83c6de3644c8f2921eb7de0eb92fac3
I believe this requires some refactoring to fix. It would be good to do that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5862: Postgres dumps core upon a connection attempt
On 02/03/2011 11:15 PM, Matt Zinicola wrote: I re-compiled with '--enable-debug' and got the symbols. The pastebin is at http://pastebin.com/xMhEHFdT That's really interesting. It's getting a NULL path pointer when - I think - it tries to determine the location of the executables. Presumably this is something bizarre in your environment - but I have no idea what it might be. Maybe someone else reading will have an idea. (Please reply-to-all on further messages so the -bugs list sees things) -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5862: Postgres dumps core upon a connection attempt
Craig Ringer writes: > On 02/03/2011 11:15 PM, Matt Zinicola wrote: >> I re-compiled with '--enable-debug' and got the symbols. The pastebin is at >> http://pastebin.com/xMhEHFdT > That's really interesting. It's getting a NULL path pointer when - I > think - it tries to determine the location of the executables. Hmm ... gdb is evidently lying to us to some extent, because some of those variables can't possibly be NULL, and control wouldn't have got to where it says if others of them were. However, it seems clear that it's dying while trying to determine the actual location of the initdb executable. Are there any symlinks involved in the path /usr/local/pgsql/bin/initdb ? Is that located on an unusual filesystem? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Problem regarding Postgresql installation and ODBC driver installation in 64 bit Windows Vista OS.
Hello Sir/Madam, I am unable to install Postgresql "*Installer version Version 9.0.3-1 winx86-64" on my HP 64 bit laptop dv6000 series having Windows Vista OS.* * * *As soon as I try to run executable file for installing postgresql , the program aborts from inbetween and installation is cancelled. * * * ***Moreover when I try to install "**Installer version Version 8.4.7-1* " on the same laptop. it is successfully installed. But here inspite of showing successful message of ODBC driver installation, when I try to generate a new SYSTEM DSN for ODBC connection, it never shows me an option of postgresql ODBC driver. * * *I would be very grateful if you could help me in solving these issues as I am in very crucial state of my research project and I need postgresql for database access. *
[BUGS] BUG #5865: Problem regarding Postgresql installation and ODBC driver installation in 64 bit Windows Vista OS
The following bug has been logged online: Bug reference: 5865 Logged by: Amruta Buch Email address: ayb...@gmail.com PostgreSQL version: Version 9.0.3-1 Operating system: Windows Vista Description:Problem regarding Postgresql installation and ODBC driver installation in 64 bit Windows Vista OS Details: I am unable to install Postgresql "Installer version Version 9.0.3-1 winx86-64" on my HP 64 bit laptop dv6000 series having Windows Vista OS. As soon as I try to run executable file for installing postgresql , the program aborts from inbetween and installation is cancelled. Moreover when I try to install "Installer version Version 8.4.7-1 " on the same laptop. it is successfully installed. But here inspite of showing successful message of ODBC driver installation, when I try to generate a new SYSTEM DSN for ODBC connection, it never shows me an option of postgresql ODBC driver. I would be very grateful if you could help me in solving these issues as I am in very crucial state of my research project and I need postgresql for database access. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5866: Binary replication - default port
The following bug has been logged online: Bug reference: 5866 Logged by: Inya Email address: sm...@mail.ee PostgreSQL version: 9.0.3 Bitnami Operating system: Linux Debian Description:Binary replication - default port Details: It's probably not a bug, but worth considering to others, who are installing binary replication. If the master server is not installed on the default port - 5432 - then it's NOT going to accept replication from slaves. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5866: Binary replication - default port
On Fri, Feb 4, 2011 at 07:22, Inya wrote: > > The following bug has been logged online: > > Bug reference: 5866 > Logged by: Inya > Email address: sm...@mail.ee > PostgreSQL version: 9.0.3 Bitnami > Operating system: Linux Debian > Description: Binary replication - default port > Details: > > It's probably not a bug, but worth considering to others, who are installing > binary replication. It's certainly not a bug. > If the master server is not installed on the default port - 5432 - then it's > NOT going to accept replication from slaves. Yes, it will. On the port that you specified. It will not accept connections on a port it's not configured. Regardless of client, whether it's a replication client, or psql, or pgadmin, or your application. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
