Re: [NOVICE] Re: [GENERAL] Postgres superuser priviledges - Mailing list pgsql-general

From Gene Selkov, Jr.
Subject Re: [NOVICE] Re: [GENERAL] Postgres superuser priviledges
Date
Msg-id 35B6C7BA.F26C19A8@mcs.anl.gov
Whole thread Raw
In response to Re: [NOVICE] Re: [GENERAL] Postgres superuser priviledges  (Konstantinos Vassiliadis <vassilik@p05.cs.man.ac.uk>)
List pgsql-general
Konstantinos Vassiliadis wrote:

> I have issued
>  %make
> from the directory where all my files are and gave
> make: *** ..: Is a directory.  Stop.
>
> I attach the C source, the SQL definitions and my Makefile.

[snip]

This is just to inform you of the status of your project as it would
stand now in a less hostile environment. Congratulations, you almost
made it. You still have some problem in your c code that I don't
understand (scanf? use of pointers?). I'll give it another shot
tomorrow.

Here is an account of the problems you apparently ran across.


A number of things were wrong in your makefile, mostly invisible ones.

1. The lines were terminated with '\r' which can upset some versions of
make and compilers. I cure this problem with

perl -i.b -npe 's/\r//g' * ; rm -f *.b


2. If you omit space here:

DLOBJS+= $(DLOBJS:.o=$(EXPSUFF))
        ^----thius one

It complains about

Makefile:23: *** missing `endif'

 The cause is difficult to find. I could only arrive there through
comparison.

3. Rules in targets should always start with a tab. That's not just
style, it is part of the syntax. Failure to place a tab between a target
and its rules (or between these) results in

Makefile:19: *** missing separator.


4. Includes at the top of the Makefile must refer to the postgres source
directory and the top level Makefile, respectively.


In the c code,


1. should be no main() -- linker will complain and probably bail out
because of unresolved symbol

2. should be no printf() -- because there is no stdout. Use
fprintf(stderr,
...), it will write to the backend logfile, or use fopen(file, ...) in
the append mode and fprintf(file, ...), but this requires you to have
permissions to read the backend log or the file it will create.


This is what I got wen I built the library and ran your sql:

kostas=> INSERT INTO test_phone VALUES ('01483-827294','0161-2242394');
INSERT 23502 1
kostas=> INSERT INTO test_phone VALUES ('0171-8235465','01189-887762');
INSERT 23503 1
kostas=>
kostas=> SELECT * FROM test_phone;
mynumber                     |hernumber
-----------------------------+-------------
01483m820161-820161          |0161-22
0171',8201189m88¸-8201189m88¸|01189m88¸-88¸
(2 rows)


There is almost no way to debug *_in() functions from within themselves,
but I found it useful to define a set of simple procedures (sort of
_out()) that retrieve only one structure element at a time and return it
as a string. That way, if something goes wrong, you can be almost sure
it is not in the output. In your example, you could define a function
area_code() and do the following select:

select area_code(mynumber) from test_phone;


Gene

pgsql-general by date:

Previous
From: Kevin Cousins
Date:
Subject: Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
Next
From: Maarten Boekhold
Date:
Subject: Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]