The attached patches will allow postgreSQL to compile successfully on SCO
UNIXWARE 2.1.x. The patches fix the following problems:
1. Configure did not properly recognize the UNIXWARE system as needing the
univel port. It used the sys4 port.
2. Configure did not properly process the CC flag in the template file.
3. There was no working test and set locking implementation for the native
UNIXWARE compiler.
4. The test and set locking used for Intel X86 that was selected by defining
NEED_I386_TAS_ASM could fail in a multi-processor environment.
5. The makefiles for libpq and libpgtcl did not make a shared library for
the univel port.
varchar length.
Cleans up code so attlen is always length.
Removed varchar() hack added earlier.
Will fix bug in selecting varchar() fields, and varchar() can be
variable length.
nodeAgg.c: WARN -> NOTICE for elog
parse_oper.c: was created after patch for fmgr_info, so function call wrong
scan.c: regenerated for i386_solaris using flex 2.5.4
gethostname.c: required prototype for gethostname() function
config.h.in: create prototype for isinfo() function
isinf.c: "fake" isinf() under i386_solaris using fpclass() call...
Patch by: wieck@sapserv.debis.de (Jan Wieck)
One of the design rules of PostgreSQL is extensibility. And
to follow this rule means (at least for me) that there should
not only be a builtin PL. Instead I would prefer a defined
interface for PL implemetations.
Pass List* of Aggregs into executor, and create needed array there.
No longer need to double-processs Aggregs with second copy in Query.
Fix crash when doing:
select sum(x+1) from test where 1 > 0;
OK, here comes a patch, DBD::Pg (and possibly other 3rd party clients)
can connect to unix sockets.
Patch is against current source tree.
Background:
libpq set some policy for client, which it should not
IMHO. It prevent some 3rd party clients to connect with
unix domain sockets etc.
reference to the name of the shared library, instead of dereferencing
the definition from the top of the file.
From: Tom I Helbekkmo <tih@Hamartun.Priv.NO>
==========================================
What follows is a set of diffs that cleans up the usage of BLCKSZ.
As a side effect, the person compiling the code can change the
value of BLCKSZ _at_their_own_risk_. By that, I mean that I've
tried it here at 4096 and 16384 with no ill-effects. A value
of 4096 _shouldn't_ affect much as far as the kernel/file system
goes, but making it bigger than 8192 can have severe consequences
if you don't know what you're doing. 16394 worked for me, _BUT_
when I went to 32768 and did an initdb, the SCSI driver broke and
the partition that I was running under went to hell in a hand
basket. Had to reboot and do a good bit of fsck'ing to fix things up.
The patch can be safely applied though. Just leave BLCKSZ = 8192
and everything is as before. It basically only cleans up all of the
references to BLCKSZ in the code.
If this patch is applied, a comment in the config.h file though above
the BLCKSZ define with warning about monkeying around with it would
be a good idea.
Darren darrenk@insightdist.com
(Also cleans up some of the #includes in files referencing BLCKSZ.)
==========================================
> then you try get substr, which consists only of last char in string
> you get all string
>
> For example:
> userbase=> select substr('123456', 6,1) ;
> substr
> ------
> 123456
> (1 row)
>
From Edmund Mergl <E.Mergl@bawue.de>
Bruce Momjian
Marc G. Fournier
PostgreSQL Daemon
Vadim B. Mikheev