[BUGS] A couple of ecpg issues in CVS tip

[Tom Lane]

I'm noticing a couple of unexpected warnings on an x86_64 machine:

descriptor.c: In function 'ECPGset_desc':
descriptor.c:506: warning: passing argument 1 of 'ECPGget_variable' from 
incompatible pointer type

This probably needs the same hack as in execute.c.

pgc.l:1094: warning, -s option given but default rule can be matched

This indicates a "hole" in the lexer rules.   Probably needs looking at.
(This machine has flex 2.5.31.  Curiously, I see no such warning with
flex 2.5.4 ... so it might be bogus.)

regards, tom lane

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [BUGS] BUG #1956: Plpgsql top-level DECLARE does not share scope

[Jim C. Nasby]

On Thu, Oct 13, 2005 at 04:24:23PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Thu, Oct 13, 2005 at 01:30:56PM -0400, Tom Lane wrote:
> >> Basically, DECLARE introduces a new name scope that wouldn't be there
> >> if you didn't say DECLARE.  Without some bizarre reinterpretation of the
> >> meaning of a DECLARE at the start of a function, variables automatically
> >> created by plpgsql are going to be in an outer scope surrounding that of
> >> the first DECLARE.
> 
> > Another possibility is tracking what level sub-block something is in,
> > and using that to determine if the top-most declare in a function is
> > over-writing something.
> 
> BTW, another issue here is that if we did merge the first DECLARE with
> the scope of auto-declared variables, it would be a non backwards
> compatible change.  Right now you can do, say,

I wasn't suggesting that we actually merge the scopes; is it possible to
detect over-writing a variable without merging them?

>   declare found int;
> 
> and it'll override the standard FOUND variable.  If we change this then
> you'd get an error.  (Of course, it could be argued that that would be
> a Good Thing.  But it would inhibit us from adding new auto-declared
> variables that are less central to the language than FOUND, because of
> the risk of breaking existing code.)

I thought we were only talking about throwing a warning, not an error. I
don't think it makes sense to throw an error for any of these cases,
because it could well be what the user wants, but it would be nice to
warn them since there's a good chance it's a mistake (especially in the
top-level).
-- 
Jim C. Nasby, Sr. Engineering Consultant  [EMAIL PROTECTED]
Pervasive Software  http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf   cell: 512-569-9461

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

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

Re: [BUGS] [GENERAL] Postgres logs to syslog LOCAL0

[Tom Lane]

[ redirecting to a more appropriate list ]

[EMAIL PROTECTED] writes:
> I've noticed that, even though I specified LOCAL5 as syslog facility, 
> postgres 
> nevertheless logs _some_ events to LOCAL0. 

I've thought of a theory about this: if the first write_syslog() call
occurs before guc.c has read the config file and set Syslog_facility
to LOCAL5, then the facility value would get locked down as the default
LOCAL0 and subsequently never changed.

Since write_syslog() certainly wouldn't be called until Log_destination
is changed from its default, the triggering situation would have to be
an elog call occuring between the assignments to Log_destination and
Syslog_facility --- ie, an elog coming from guc.c itself.  But that
doesn't seem out of the question at all.

The problem with this theory as an explanation for Han's report is that
he says only "some" events are reported to LOCAL0.  Under this theory
a postmaster that had gotten into this mode would *always* report to
LOCAL0, and so would all its children (at least in non-EXEC_BACKEND
builds, which is to say any non-Windows build).  Han, can you quantify
"some" any better?

> Log lines look like:
> Oct 14 08:55:02 pavenlo  root palga [local] SELECT: [17-1] LOG:  duration: \ 
> 2953.658 ms  statement: select rapnaam from udps where ((geboortedatum = \ 
> '1954-01-21') and (naamman ~ '^thie'))
> Oct 14 08:55:02 pavenlo  root palga [local] SELECT: [17-2]  limit 1000

Another strange thing here is that the funny log entries don't show the
PID of the originating process.  Since we *always* call openlog() with
the LOG_PID flag bit, this should be impossible.

> +preload_libraries = 
> '/usr/prod/postgres/rubriek:rub_initialize,/usr/prod/postgres/drap,/usr/prod/postgres/naam'

Han, what are these libraries?  Is it possible that any of them are
issuing openlog() calls?

regards, tom lane

---(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: [BUGS] BUG #1963: SSL certificate permission check is too strict

[Tom Lane]

"Martin Pitt" <[EMAIL PROTECTED]> writes:
> Currently the postmaster requires the private SSL key file to have the same
> owner as the postmaster, and no permissions for group and others. However,
> this is too strict to sensibly use the certificate with ACLs, which permits
> other server processes to share it.

> In Debian I applied a patch which relaxes the check a bit: in addition to
> the currently allowed permissions, the file might be:
>  - owned by root
>  - group-readable if the file is in group root or the postmaster group.

This was proposed and rejected before --- it's not clear why it's a good
idea to share a private key file with other servers, and even less clear
why it'd be a good idea to have such a file be group-readable by a large
group.

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [BUGS] Bug#333854: pg_group file update problems

[Bruce Momjian]

Tom Lane wrote:
> Dennis Vshivkov <[EMAIL PROTECTED]> writes:
> > The problem is that the code that updates pg_group file resolves
> > group membership through the system user catalogue cache.
> 
> Good catch.
> 
> > The attached `98-6-pg_group-stale-data-fix.patch' makes the code
> > in question access the system user table directly and thus fixes
> 
> Wouldn't a CommandCounterIncrement be a much simpler solution?
> 
> Since this code is all gone in CVS tip, there's not going to be any way
> of beta-testing a large patch ... and there's also not going to be a lot
> of support for pushing a large, poorly tested patch into the back
> branches.

It is pretty clear where we are missing group_file_update_needed() in
user.c.  We did not anticipate the group being modified by CREATE USER,
so adding the group_file_update_needed() seems trivial.

If a CommandCounterIncrement() fixes the problem, that also seems like a
trivial addition.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@candle.pha.pa.us   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [BUGS] Bug#333854: pg_group file update problems

[Tom Lane]

Dennis Vshivkov <[EMAIL PROTECTED]> writes:
> The problem is that the code that updates pg_group file resolves
> group membership through the system user catalogue cache.

Good catch.

> The attached `98-6-pg_group-stale-data-fix.patch' makes the code
> in question access the system user table directly and thus fixes

Wouldn't a CommandCounterIncrement be a much simpler solution?

Since this code is all gone in CVS tip, there's not going to be any way
of beta-testing a large patch ... and there's also not going to be a lot
of support for pushing a large, poorly tested patch into the back
branches.

regards, tom lane

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

Re: [BUGS] BUG #1964: Role membership error

[Tom Lane]

"Kevin Walker" <[EMAIL PROTECTED]> writes:
>ERROR: role "dbadmin" is a member of role "kw"

> The message suggests that the login role "kw" is already a member of group
> role "dbadmin" which is not the case.

I think you are reading it backwards.  You're probably accidentally
trying to set up circular role memberships, which isn't allowed.
Observe:

regression=# create role dbadmin;
CREATE ROLE
regression=# create role kw;
CREATE ROLE
regression=# grant kw to dbadmin;
GRANT ROLE
regression=# grant kw to dbadmin;
NOTICE:  role "dbadmin" is already a member of role "kw"
GRANT ROLE
regression=# grant dbadmin to kw;
ERROR:  role "dbadmin" is a member of role "kw"

Note that re-granting is only a NOTICE not an ERROR.

regards, tom lane

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

Re: [BUGS] BUG #1956: Plpgsql top-level DECLARE does not share

[Michael Fuhr]

On Thu, Oct 13, 2005 at 03:51:15PM +, Karl O. Pinc wrote:
> I definately do not recall catching any additional errors at
> compile time as part of the switch to 8.

8.0's syntax checking is minimal; 8.1's will be better.  Also, you
might not even have plpgsql's lanvalidator function if you restored
from an earlier version.  What's the result of the following query?

SELECT * FROM pg_language WHERE lanname = 'plpgsql';

If lanvalidator is 0 then you won't get even the minimal syntax
checks.  8.1 will avoid this problem by creating languages based
on entries in a template table (pg_pltemplate).

-- 
Michael Fuhr

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

[BUGS] BUG #1963: SSL certificate permission check is too strict

[Martin Pitt]

The following bug has been logged online:

Bug reference:  1963
Logged by:  Martin Pitt
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.1beta3
Operating system:   Debian
Description:SSL certificate permission check is too strict
Details: 

Currently the postmaster requires the private SSL key file to have the same
owner as the postmaster, and no permissions for group and others. However,
this is too strict to sensibly use the certificate with ACLs, which permits
other server processes to share it.

In Debian I applied a patch which relaxes the check a bit: in addition to
the currently allowed permissions, the file might be:
 - owned by root
 - group-readable if the file is in group root or the postmaster group.

Since this likely affects non-Debian server installations as well, do you
consider adopting this?

Thanks!

Martin

Original Debian bug report:
http://bugs.debian.org/327901

Debian patch against 8.1beta3:
http://people.debian.org/~mpitt/09-relax-sslkey-permscheck.patch

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

Re: [BUGS] BUG #1964: Role membership error

[Bruce Momjian]

Kevin Walker wrote:
> 
> The following bug has been logged online:
> 
> Bug reference:  1964
> Logged by:  Kevin Walker
> Email address:  [EMAIL PROTECTED]
> PostgreSQL version: 8.1 beta 3
> Operating system:   Windows XP
> Description:Role membership error
> Details: 
> 
> I created a group role called dbadmin and assigned it the privileges that I
> wanted.  I then created a new login role and attempted to add this new login
> as a member in the group role.  The following error is generated in pgAdmin
> III and when the same steps are performed manually.
> 
>ERROR: role "dbadmin" is a member of role "kw"
> 
> The message suggests that the login role "kw" is already a member of group
> role "dbadmin" which is not the case.  Using the alter group command also
> produces the same error.
> 
> This problem is occurring on the build for Windows.  I have not tested this
> process on a Linux build yet.

What were you trying, exactly?   It worked for me:

test=> CREATE ROLE dbadmin;
CREATE ROLE
test=> CREATE ROLE kw;
CREATE ROLE
test=> GRANT dbadmin TO kw;
GRANT ROLE

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@candle.pha.pa.us   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [BUGS] BUG #1962: ECPG and VARCHAR

[Michael Meskes]

On Thu, Oct 13, 2005 at 11:18:13AM -0500, C Wegrzyn wrote:
>  Yes I found out the same thing. Unfortunately it isn't quite that
> simple for me. It isn't a very good idea to hard-code fixed sizes in
> executables. I have a file with all sorts of #defines in it. If the bug
> doesn't get fixed it means that I will need to run CPP over the code
> before I run ecpg, which is just ugly.

Can't you just compile a new version of ecpg with the patch Bruce
committed? Depending on the system you're using I could even send you a
binary.

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

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

Re: [BUGS] BUG #1962: ECPG and VARCHAR

[Michael Meskes]

On Thu, Oct 13, 2005 at 09:53:14PM -0400, Bruce Momjian wrote:
> Good catch!  I have backpatched these fixes to the 8.0 and 7.4 branches
> as you suggested, (identical) patches attached.

Thanks Bruce. This was an oversight on my part. I should have committed
to 8.0 branch too. I'm sorry about that.

On the other hand I agree with Tom. Fortunately it's not a data corruption 
problem.
:-)

Michael

-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

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

Re: [BUGS] BUG #1966: Single OUT PARM does not return param name.

[Bruce Momjian]

Tony Caduto wrote:
> 
> The following bug has been logged online:
> 
> Bug reference:  1966
> Logged by:  Tony Caduto
> Email address:  [EMAIL PROTECTED]
> PostgreSQL version: 8.1
> Operating system:   Linux
> Description:Single OUT PARM does not return param name.
> Details: 
> 
> When creating a plpgsql function that has one OUT param the function returns
> the name of the function as the column name instead of the OUT param name.
> This behavior is not consistant with the behavior of other DB systems and
> needs to be fixed so that if a single OUT param is specifed the name of the
> param is returned.

This will be fixed in 8.1beta3.  Thanks for the report.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@candle.pha.pa.us   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(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

[BUGS] BUG #1966: Single OUT PARM does not return param name.

[Tony Caduto]

The following bug has been logged online:

Bug reference:  1966
Logged by:  Tony Caduto
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.1
Operating system:   Linux
Description:Single OUT PARM does not return param name.
Details: 

When creating a plpgsql function that has one OUT param the function returns
the name of the function as the column name instead of the OUT param name.
This behavior is not consistant with the behavior of other DB systems and
needs to be fixed so that if a single OUT param is specifed the name of the
param is returned.

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

[BUGS] BUG #1965: documentation

[Wilmar Yesid Calderón Franco]

The following bug has been logged online:

Bug reference:  1965
Logged by:  Wilmar Yesid Calderón Franco
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.0
Operating system:   Windows XP
Description:documentation
Details: 

information about new versions.

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

[BUGS] Bug#333854: pg_group file update problems

[Dennis Vshivkov]

Package: postgresql-8.0
Version: 8.0.3-13
Severity: important
Tags: patch, upstream

Here's the problem:

db=# CREATE GROUP g1;
CREATE GROUP
db=# CREATE USER u1 IN GROUP g1;(1)
CREATE USER

# cat /var/lib/postgresql/8.0/main/global/pg_group
#

The file gets rewritten, but the group `g1' line does not get
added to the file.  Continue:

db=# CREATE USER u2 IN GROUP g1;(2)
CREATE USER

# cat /var/lib/postgresql/8.0/main/global/pg_group
"g1""u1"
#

Now the line is there, but it lacks the latest member.  Consider
this also:

db=# ALTER USER u2 RENAME TO u3;(3)
ALTER USER

# cat /var/lib/postgresql/8.0/main/global/pg_group
"g1""u1" "u2"
#

The problem is that the code that updates pg_group file resolves
group membership through the system user catalogue cache.  The
file update happens shortly before the commit, but the caches
only see updates after the commit.  Because of this, new users
or changes in users' names often do not make it to pg_group.
That leads to mysterious authentication failures subsequently.
The problem can also have security implications for certain
pg_hba.conf arrangements.

The attached `98-6-pg_group-stale-data-fix.patch' makes the code
in question access the system user table directly and thus fixes
the cases (1) and (2), however (3) is doubly ill: the user
renaming code does not even trigger a pg_group file update.
Hence the other patch, `98-5-rename-user-update-pg_group.patch'.

A byproduct of the main fix is removal of an unlikely system
cache reference leak which happens if a group member name
contains a newline.

The problems were found and the fixes were done for PostgreSQL
8.0.3 release.  The flaws seem intact in 8.0.4 source code, too.

Hope this helps.

-- 
/Awesome Walrus <[EMAIL PROTECTED]>
--- build-tree/postgresql-8.0.3/src/backend/commands/user.c.orig
2005-05-31 14:55:27.0 +1200
+++ build-tree/postgresql-8.0.3/src/backend/commands/user.c 2005-05-31 
14:55:30.0 +1200
@@ -1286,6 +1286,7 @@ RenameUser(const char *oldname, const ch
heap_close(rel, NoLock);
 
user_file_update_needed();
+   group_file_update_needed();
 }
 
 
--- build-tree/postgresql-8.0.3/src/backend/commands/user.c.orig
2005-10-14 11:00:16.0 +1300
+++ build-tree/postgresql-8.0.3/src/backend/commands/user.c 2005-10-14 
11:01:09.0 +1300
@@ -17,6 +17,7 @@
 #include 
 #include 
 
+#include "access/genam.h"
 #include "access/heapam.h"
 #include "catalog/catname.h"
 #include "catalog/indexing.h"
@@ -154,6 +155,27 @@
HeapScanDesc scan;
HeapTuple   tuple;
TupleDesc   dsc = RelationGetDescr(grel);
+   /* Look up user names by user system id. */
+   Relationurel = heap_openr(ShadowRelationName, AccessShareLock),
+   ureli = index_openr(ShadowSysidIndex);
+
+   /* Scan for system id equality. */
+   ScanKeyData ukey =
+   {
+   .sk_flags   = 0,
+   .sk_attno   = 1,
+   .sk_strategy= BTEqualStrategyNumber,
+   .sk_subtype = InvalidOid
+   };
+
+   /* We expect the first index column to be in order. */
+   Assert(Anum_pg_shadow_usesysid == ureli->rd_index->indkey[0]);
+
+   /* And only one system identifier column type. */
+   Assert(RelationGetDescr(urel)->attrs[Anum_pg_shadow_usesysid - 
1]->atttypid == INT4OID);
+
+   /* Finish scan key initialisation. */
+   fmgr_info(F_INT4EQ, &ukey.sk_func);
 
/*
 * Create a temporary filename to be renamed later.  This prevents the
@@ -192,6 +214,7 @@
num;
char   *usename;
boolfirst_user = true;
+   IndexScanDesc userscan;
 
datum = heap_getattr(tuple, Anum_pg_group_groname, dsc, 
&isnull);
/* ignore NULL groupnames --- shouldn't happen */
@@ -221,11 +244,12 @@
/* scan grolist */
num = IDLIST_NUM(grolist_p);
aidp = IDLIST_DAT(grolist_p);
-   for (i = 0; i < num; ++i)
+   for (i = 0; i < num; ++i, index_endscan(userscan))
{
-   tuple = SearchSysCache(SHADOWSYSID,
-  
PointerGetDatum(aidp[i]),
-  0, 0, 0);
+   ukey.sk_argument = PointerGetDatum(aidp[i]);
+   userscan = index_beginscan(urel, ureli, SnapshotSelf, 
1, &ukey);
+   tuple = index_getnext(userscan, ForwardScanDirection);
+
if (HeapTupleIsValid(tuple))
{
usename = NameStr(((Form_pg_shadow) 
GETSTRUCT(tuple))->usename);
@@ -254,8 +278,6 @@
 
 

Re: [BUGS] BUG #1956: Plpgsql top-level DECLARE does not share

[Karl O. Pinc]

On 10/13/2005 09:38:36 AM, Bruce Momjian wrote:


> Fair enough.  At the same time it sure would be nice if
> plpgsql actually compiled (and parsed SQL) at
> function definition time, even when the result is thrown away.
> I'm building a big system and it's quite annoying
> to get syntax errors, IIRC,
> in code months after writing it, just because it took
> me that long to get around to exercising a particular
> IF statement.

8.0 has this improvement:

 * Do minimal syntax checking of PL/pgSQL functions at creation
time (Tom)
   This allows us to catch simple syntax errors sooner.

I assume you are running an earlier version of PostgreSQL.


I was, but switched to 8.0.2 and then 8.0.3 as soon as it came out.

Perhaps my problems are more to do with not-simple syntax errors,
or I could be recalling my experience before 8.0.x.  I definately
do not recall catching any additional errors at compile time as
part of the switch to 8.  Call it paranoia, I'm still not
confident.  More compile time checks are better!
Gimmie!
Mine!
*Ahem*...

Ok.  Thanks for the reply.  I'm done with the bulk of the code
at this point but I'll keep a lookout for cases where
syntax/datatype errors crop up out of the blue.

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein


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

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

Re: [BUGS] BUG #1962: ECPG and VARCHAR

[C Wegrzyn]

Michael Fuhr wrote:

>On Thu, Oct 13, 2005 at 02:24:27PM +0100, Charles Wegrzyn wrote:
>  
>
>>I have code that under 8.0.3 works:
>>
>>  VARCHAR t[MAX_TENANT_SIZE+1];
>>  VARCHAR o[MAX_OID_SIZE+1];
>>
>>In 8.0.4 I found this throws an error during the ecpg step:
>>
>>tenant.ec:375: ERROR: pointer to varchar are not implemented
>>tenant.ec:376: ERROR: pointer to varchar are not implemented
>>
>>
>
>ecpg in 8.0.4 seems not to like the macros.  I get the same error,
>but not if I do this:
>
>VARCHAR  t[256];
>VARCHAR  o[256];
>
>ecpg in 8.1beta3 works either way.
>
>  
>
Michael,

 Yes I found out the same thing. Unfortunately it isn't quite that
simple for me. It isn't a very good idea to hard-code fixed sizes in
executables. I have a file with all sorts of #defines in it. If the bug
doesn't get fixed it means that I will need to run CPP over the code
before I run ecpg, which is just ugly.

Chuck Wegrzyn


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

Re: [BUGS] BUG #1959: readline error exiting psql

[David Wheeler]

On Oct 13, 2005, at 9:54 AM, Tom Lane wrote:


Are you sure this bug report shouldn't be directed to Apple?


Of course it should. I only directed it to you because I had thought  
you figured out a workaround for it. If there isn't a workaround, I  
won't report it again. :-)


Thanks,

David


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

Re: [BUGS] building Postgresql 7.3.10 on Mac OS X 10.4

[Peter Bazeley]

  
  

  Hi Tom,

 

  Thanks, that got me passed that step, but make failed on another. My production site is stuck with 7.3.10 (RHEL 3.0), and I would like to have a separate development site on a OS X 10.4 machine, but alas, it seems I'll have to keep them together.

 
 

  Thanks all for input,


  Pete

 
Peter Bazeley, M.Sc.Database Specialist / ResearchBioinformatics and Proteomics / GenomicsMedical University of OhioToledo, Ohio 43614-5806>>>Tom Lane <[EMAIL PROTECTED]> 10/13/05 11:42 am >>>

 
"Peter Bazeley" <[EMAIL PROTECTED]> writes:

 
>I am trying to build Postgresql 7.3.10 on Mac OS X 10.4 and am getting a =

 
>couple errors related to bootstrap libraries. These are occuring during =

 
>make -C bootstrap all. Here is the output:=20

 
>make -C bootstrap all=20

 
>gcc -traditional-cpp -g -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes=

 
> -Wmissing-declarations -I. -I../../../src/include -I/sw/include/  -c -o =

 
 
For more recent versions of OS X (since 10.2 I think), you need

 
-no-cpp-precomp instead of -traditional-cpp.  PG 7.3.* is too old to

 
know about that ... you can probably fix this in src/template/darwin,

 
but it may not be the last such gotcha.  Are you sure you want such an

 
old PG version?  I'd currently recommend the 8.0 branch for production

 
and 8.1 for development.

 
 
regards, tom lane
  



On June 8, 2005, the Medical College of Ohio's name changed to the Medical University of Ohio.

Please note that any contacts stored in your personal address book with the extension of mco.edu should now be changed to meduohio.edu to avoid any interruptions in email delivery.

CONFIDENTIALITY NOTICE:
This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

Re: [BUGS] BUG #1956: Plpgsql top-level DECLARE does not share

[Karl O. Pinc]

On 10/13/2005 03:24:23 PM, Tom Lane wrote:

"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Thu, Oct 13, 2005 at 01:30:56PM -0400, Tom Lane wrote:
>> Basically, DECLARE introduces a new name scope that wouldn't be
there
>> if you didn't say DECLARE.  Without some bizarre reinterpretation
of the
>> meaning of a DECLARE at the start of a function, variables
automatically
>> created by plpgsql are going to be in an outer scope surrounding
that of
>> the first DECLARE.

BTW, another issue here is that if we did merge the first DECLARE with
the scope of auto-declared variables, it would be a non backwards
compatible change.


How about merging only the auto-declared function arguments into the
first DECLARE?  Down side would be that I can see that causing
an actual error instead of a warning if somebody wants to shadow
one of the function arguments with their own declaration.


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

P.S.
Seems that as of today I can no longer write Bruce Momjian
.  :-(  This showed up in a bounce:

-
Hi. This is the qmail-send program at mail27.sea5.speakeasy.net.



:
64.139.89.126 does not like recipient.
Remote host said: 550 5.0.0 ... Delivery  
blocked ---

Previous SPAM received from your mail server
Giving up on 64.139.89.126.


---(end of broadcast)---
TIP 6: explain analyze is your friend

[BUGS] BUG #1967: Respons(Binary) is not correctly by PQexecParams

[tadayoshi sato]

The following bug has been logged online:

Bug reference:  1967
Logged by:  tadayoshi sato
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.0.4
Operating system:   WindowsXp ,Linux (redhat9)
Description:Respons(Binary) is not   correctly by PQexecParams
Details: 

When character-string data is demanded with PQexecParams in the binary, it
is not correct. 
However, character-string data is a server: EUC-JP and client: It is
SHIFTJIS. 
It is because it is not NULL stop though the cause passes the character
string to convert the code in pq_sendtext.

---(end of broadcast)---
TIP 6: explain analyze is your friend

[BUGS] BUG #1964: Role membership error

[Kevin Walker]

The following bug has been logged online:

Bug reference:  1964
Logged by:  Kevin Walker
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.1 beta 3
Operating system:   Windows XP
Description:Role membership error
Details: 

I created a group role called dbadmin and assigned it the privileges that I
wanted.  I then created a new login role and attempted to add this new login
as a member in the group role.  The following error is generated in pgAdmin
III and when the same steps are performed manually.

   ERROR: role "dbadmin" is a member of role "kw"

The message suggests that the login role "kw" is already a member of group
role "dbadmin" which is not the case.  Using the alter group command also
produces the same error.

This problem is occurring on the build for Windows.  I have not tested this
process on a Linux build yet.

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