Hi,
Section 3.3, tutorial-fk.html
CREATE TABLE cities (
namevarchar(80) primary key,
locationpoint
);
CREATE TABLE weather (
cityvarchar(80) references weather,
temp_lo int,
temp_hi int,
prcp
[EMAIL PROTECTED] writes:
> Section 3.3, tutorial-fk.html
> You have written 'references weather' instead of 'references cities'.
This seems to be fixed already.
> Line 9 refers to 'advanced' instead of 'syscat' in syscat.py
Good catch, thanks for the report!
regards,
In some plpgsql method, I call some C function with a optional parameters.
This is the signature of my function :
extern "C" My_Mem_Macro_Parser_Integer myMethod( int nbFields, int toto
= -1)
{
blablabla .
return integer;
}
When I call this function with the second parameters, there's no
Alban =?ISO-8859-1?Q?M=E9dici?= <[EMAIL PROTECTED]> writes:
> extern "C" My_Mem_Macro_Parser_Integer myMethod( int nbFields, int toto
> = -1)
Default parameters are a C++-ism that doesn't exist in C, and certainly
is entirely unknown to CREATE FUNCTION. You'll have to make two
distinct function
Default parameters are filled in by the C++ compiler. You must provide
them when calling from a non-C++ program.
-Original Message-
From: Alban Médici [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 03, 2002 10:57 AM
To: plpgsql
Subject: [BUGS] Strange Behavior when calling a C function by
Hello.
I am new to the bugs list, so I hope this hasn't been covered before, but
I have a Slackware 8.0 system that is fairly up to date. Possibly to a
fault. Glibc is 2.2.5, gcc is 2.95.3, zlib is 1.1.4, kernel is 2.4.18
with the GRSecurity patch.
I have been trying to run Postgres 7.2.1 in
Hey guys... second post of the day. If you read my last post about
Postgres 7.2.1 segfaulting on Slackware 8.0, you noted I am trying to
chroot Postgres. Unfortunately, my chrooted postgres cannot create
databases due to a 'system' call, which runs '/bin/sh'. Having the shell
in my chroot kind
Stephen Amadei <[EMAIL PROTECTED]> writes:
> I have been trying to run Postgres 7.2.1 in a chrooted environment, but
> once I try to connect to the server with a "psql -l", it segfaults as it
> tries to read from the data/global/1262.
Urgh. Can you provide a stack trace?
Stephen Amadei <[EMAIL PROTECTED]> writes:
> Hey guys... second post of the day. If you read my last post about
> Postgres 7.2.1 segfaulting on Slackware 8.0, you noted I am trying to
> chroot Postgres. Unfortunately, my chrooted postgres cannot create
> databases due to a 'system' call, which r
On Fri, 3 May 2002, Tom Lane wrote:
> Stephen Amadei <[EMAIL PROTECTED]> writes:
> > I have been trying to run Postgres 7.2.1 in a chrooted environment, but
> > once I try to connect to the server with a "psql -l", it segfaults as it
> > tries to read from the data/global/1262.
>
> Urgh. Can you
Stephen Amadei <[EMAIL PROTECTED]> writes:
>> Urgh. Can you provide a stack trace?
> You mean using strace? Yeah. The strace created quite a bit of logs, but
> the process that segfaulted is included below.
> open("/usr/local/pgsql/data/global/1262", O_RDONLY) = 4
> read(4, "\0\0\0\0\f\222\20
On Fri, 3 May 2002, Tom Lane wrote:
> Stephen Amadei <[EMAIL PROTECTED]> writes:
> >> Urgh. Can you provide a stack trace?
>
> > You mean using strace? Yeah. The strace created quite a bit of logs, but
> > the process that segfaulted is included below.
>
> > open("/usr/local/pgsql/data/global/
On Fri, 3 May 2002, Tom Lane wrote:
> > While, IMHO, the safest way to do this would be to code the cp and rm code
> > internally, I have patched my copy to do a fork and execl to call the cp
> > and rm programs directly (and placed /bin/cp and /bin/rm in the chroot
> > jail) as a quick fix... I
13 matches
Mail list logo
