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...
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
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
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
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
Steve White writes:
> It would be advantageous to have a portable, simple means of including
> a module from the distribution contrib/ directory.
Please have a look at the Extension patch section here:
https://commitfest.postgresql.org/action/commitfest_view?id=9
Regards,
--
Dimitri Fontaine
The following bug has been logged online:
Bug reference: 5860
Logged by: Yuvachitra
Email address: yuvachi...@gmail.com
PostgreSQL version: 8.3/ 9.0
Operating system: Windows 2003
Description:initdb failing with could not create directory
"C:/Program Files ": File exi
The following bug has been logged online:
Bug reference: 5861
Logged by: Pankaj Singh
Email address: er1.pan...@gmail.com
PostgreSQL version: 9.0.2
Operating system: Window XP
Description:lo_import and lo_export methods not working from the
client side if database is
The following bug has been logged online:
Bug reference: 5862
Logged by: Matt Zinicola
Email address: m...@zinicola.com
PostgreSQL version: 9.0.3
Operating system: Linux (Fedora 14, kernel 2.6.35-10-74), 64-bit
Description:Postgres dumps core upon a connection attempt
"Matt Zinicola" wrote:
> PostgreSQL version: 9.0.3
> Operating system: Linux (Fedora 14, kernel 2.6.35-10-74), 64-bit
> Description: Postgres dumps core upon a connection attempt
> Details:
>
> A simple compile from source and install (as per usual) on Fedora
> 14 yielded crashes of client appl
The following bug has been logged online:
Bug reference: 5863
Logged by: R. Engmann
Email address: rengm...@web.de
PostgreSQL version: 9.0.3
Operating system: Windows 32bit
Description:help message report 5433 as default port
Details:
running postgresql-9.0.3-1-win
On 03/02/11 04:07, Matt Zinicola wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5862
> Logged by: Matt Zinicola
> Email address: m...@zinicola.com
> PostgreSQL version: 9.0.3
> Operating system: Linux (Fedora 14, kernel 2.6.35-10-74), 64-bit
> Descrip
Apologies for lack of detail. Although I've been using Postgres for
years, this is the first time I've had such an issue.
Build options were only --with-perl and --with-python
Below is the output when two different applications attempt to connect
to my 9.0.3 server (note, the second is psql itse
On 03/02/11 09:53, Matt Zinicola wrote:
> Apologies for lack of detail. Although I've been using Postgres for
> years, this is the first time I've had such an issue.
>
> Build options were only --with-perl and --with-python
>
> Below is the output when two different applications attempt to conne
Hrm.
I did see the Fedora stashed copies of libpq.so.5 and libpq.so.5.2 in
/usr/lib64. I looked everywhere on the system for libpq.so*, and saw that the
only remaining copies where those in my source directory... so I re-built
9.0.3. A 'make check' still died in the same place within the regres
On 03/02/11 10:33, Matt Zinicola wrote:
>
> Hrm.
>
> I did see the Fedora stashed copies of libpq.so.5 and libpq.so.5.2 in
> /usr/lib64. I looked everywhere on the system for libpq.so*, and saw that the
> only remaining copies where those in my source directory... so I re-built
> 9.0.3. A 'make
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 f
17 matches
Mail list logo
