Re: [SQL] Compilation Error AIX

[Andrew Sullivan]

On Thu, Feb 01, 2007 at 09:33:59AM -0600, Hiltibidal, Robert wrote:
> 
> I am getting this error

You really need to take questions about compiling to the -general
list.  I've put a Reply-To to that list, and have moved this
discussion there.  Also, it's really not a good idea to send emails
to individuals whose addresses you've pulled from the lists.

To begin with, what gcc version are you using?

Also, I see you're using the IBM "make".  Don't do that.  You need to
use gmake.  This instruction is in the documentation.  I think you
really need to read the docs.

Regards,
A

> 
> make -C port all
> 
> make[3]: Entering directory
> `/db2/logs/downloads/postgres/postgresql-8.2.1/src/backend/port'
> 
> gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
> -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing
> -I../../../src/include   -c -o dynloader.o dynloader.c
> 
> In file included from /usr/include/xcoff.h:134,
> 
>  from /usr/include/a.out.h:42,
> 
>  from dynloader.c:10:
> 
> /usr/local/include/dbug.h:38: error: syntax error before '_VARARGS'
> 
> make[3]: *** [dynloader.o] Error 1
> 
> make[3]: Leaving directory
> `/db2/logs/downloads/postgres/postgresql-8.2.1/src/backend/port'
> 
> make[2]: *** [port-recursive] Error 2
> 
> make[2]: Leaving directory
> `/db2/logs/downloads/postgres/postgresql-8.2.1/src/backend'
> 
> make[1]: *** [all] Error 2
> 
> make[1]: Leaving directory
> `/db2/logs/downloads/postgres/postgresql-8.2.1/src'
> 
> make: *** [all] Error 2
> 
>  
> 
> I found this reference on the IBM web site. The article says:
> 
> "GNU C Compiler (GCC) returns an error message if you try to #include
> varargs.h. Use stdarg.h instead."
> 
>  
> 
> http://www-128.ibm.com/developerworks/eserver/articles/linux_s390/
> 
>  
> 
> Any ideas?
> 
>  
> 
> Thanks!
> 
> -Rob
> 
>  
> 
>  
> 
>  
> 
> 
> PRIVILEGED AND CONFIDENTIAL
> This email transmission contains privileged and confidential information 
> intended only for the use of the individual or entity named above.  If the 
> reader of the email is not the intended recipient or the employee or agent 
> responsible for delivering it to the intended recipient, you are hereby 
> notified that any use, dissemination or copying of this email transmission is 
> strictly prohibited by the sender.  If you have received this transmission in 
> error, please delete the email and immediately notify the sender via the 
> email return address or mailto:[EMAIL PROTECTED]  Thank you.
> 
> 
> 

-- 
Andrew Sullivan  | [EMAIL PROTECTED]
I remember when computers were frustrating because they *did* exactly what 
you told them to.  That actually seems sort of quaint now.
--J.D. Baldwin

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

[SQL] Insert Data and autonumeric field

[André José Guergolet]

Hi everybody,
I need to insert a row in a table and get the Id of this row ( My 
primary key ).

Example:

INSERT INTO table1 (date, field2, field3) VALUES 
(now,'value2','value3');
SELECT last_value FROM seq_table1;

I'm running each command apart. My application retrieves the last_value 
and uses it in another command:

INSERT INTO table2 (pk1, field1, field2, field3) VALUES ( 
last_value_variable, 'value1','value2','value3');


PROBLEM: Many clients are getting duplicated IDs.

What is the best way of doing this?

I tried a function:

CREATE OR REPLACE FUNCTION fu_insertrow(int4, text)
  RETURNS int4 AS
$BODY$
DECLARE
i_lastvalue INTEGER;
BEGIN

INSERT INTO table1 (date, field1, field2) values 
(now(),$1,'$2');
SELECT  i_lastvalue INTO i_lastvalue from "seq_ChamadaId";
RETURN i_lastvalue;

END;
$BODY$
  LANGUAGE 'plpgsql' VOLATILE;



Using this function:

SELECT fu_insertrow(value2, value3);

The app gets the return value of the function above and uses it in my insert:
INSERT INTO table2 (pk1, field1, field2, field3) VALUES ( 
function_return_variable, 'value1','value2','value3');

Suggestions?

Thanks,
André Guergolet

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [SQL] Insert Data and autonumeric field

[Andrew Sullivan]

On Thu, Feb 01, 2007 at 04:09:22PM -0300, André José Guergolet wrote:
> PROBLEM: Many clients are getting duplicated IDs.
> 
> What is the best way of doing this?

Use a sequence.  You can get the current value of the sequence with
SELECT currval('seqname').  No, there's not a race condition; see the
docs.

A

-- 
Andrew Sullivan  | [EMAIL PROTECTED]
Information security isn't a technological problem.  It's an economics
problem.
--Bruce Schneier

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [SQL] Insert Data and autonumeric field

[Tom Lane]

=?iso-8859-1?Q?Andr=E9_Jos=E9_Guergolet?= <[EMAIL PROTECTED]> writes:
>   INSERT INTO table1 (date, field2, field3) VALUES 
> (now,'value2','value3');
>   SELECT last_value FROM seq_table1;

You should never ever look directly at the sequence table (except
perhaps for manual debugging purposes).  I think you may have confused
this with use of the lastval() function --- currval() or sometimes
lastval() are the appropriate way to get the last-assigned value.

regards, tom lane

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [SQL] Differentiate Between Zero-Length String and NULLColumn Values

[Andrew Sullivan]

On Wed, Jan 31, 2007 at 12:18:03PM -0800, BillR wrote:
> Peter Eisentraut wrote:

> >It doesn't violate any spec and it's certainly allowed by PostgreSQL 
> >without any flags.  It's just that the result is not what some people 
> >expect.

> "= NULL" violates the SQL-92 Specification.  

I don't want to put words in his mouth, but I think you missed the
bit where Peter said "the result is not what some people expect". 
Hint: 'somevalue = NULL' is not a violation of SQL in that you don't
get an ERROR.

A

-- 
Andrew Sullivan  | [EMAIL PROTECTED]
"The year's penultimate month" is not in truth a good way of saying
November.
--H.W. Fowler

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [SQL] Index Anding

[Chris Browne]

[EMAIL PROTECTED] (Andrew Sullivan) writes:
>> Does postgres provide 64 bit support? If so is there a precompiled 64
>> bit version for AIX? I have the 32 bit GCC and can compile 32 bit. 64
>> bit GCC I have not gotten stabilized. (I cold use a tip in that
>> direction if anyone lese has experienced similar issues)  
>
> I know we've managed to get it to work using gcc, but I haven't had
> to do it in a while (ask on -general or -admin, I suggest).  More
> important is to make sure you tell the compiler to use all the
> memory.  For reasons that are completely beyond my ken, AIX imposes
> a memory limitation on every program at compile time.  There are
> some hints about this in the FAQ_AIX.

Here's the environment data submitted to ./configure for a recent build of 
8.1.5:
[EMAIL PROTECTED] $ ./pg_config --configure '--prefix=/where/I/stow/it 
'--enable-thread-safety' '--enable-debug' '--with-libraries=/opt/freeware/lib' 
'--with-includes=/opt/freeware/include' 'CC=gcc -maix64' 
'LDFLAGS=-Wl,-bmaxdata:0x8000,-bbigtoc'

Note that you also need to export:
export OBJECT_MODE=64

And you need to make sure that you are using the AIX ld, and not GNU ld...

For version 7.4, it was considerably fiddlier to do a build.  For 8.2,
it is neither overly baroque nor overly unpleasant, which I consider a
direct result of the combination of Seneca Cunningham's reports to
-hackers/-ports as well as BuildFarm runs...
-- 
(reverse (concatenate 'string "ofni.sesabatadxunil" "@" "enworbbc"))
http://cbbrowne.com/info/finances.html
Rules  of the  Evil  Overlord #30.   "All  bumbling conjurers,  clumsy
squires, no-talent  bards, and  cowardly thieves in  the land  will be
preemptively put  to death.  My foes  will surely give  up and abandon
their quest if they have no source of comic relief."


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq