When building PostgreSQL 8.3 on Solaris using the configure option
--with-gssapi, libpq.so is not linked correctly.
This line in the libpq Makefile is selecting the appropriate linker
options:
---
SHLIB_LINK += $(filter -lcrypt -ldes -lcom_err -lcrypto -lk5crypto -lkrb5
-lgssapi_krb5 -lssl
Brendan Jurd escribió:
I've done up a patch per Tom's idea of combining the binary role
attributes into a single column.
This patch seems to be missing from the queue.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom
Attached is my first work at implementing GUC enums. It's not done yet,
obviously, but I did hit a problem that I need to ask about. So I'll just
send what I have now for comments.
The patch only converts a couple of the potential enum variables to the new
type, mainly as a proof of concept. But
Alvaro Herrera wrote:
Brendan Jurd escribi?:
I've done up a patch per Tom's idea of combining the binary role
attributes into a single column.
This patch seems to be missing from the queue.
Yes because I am still processing email from two weeks ago. I was in
Europe for a week.
--
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
On Fri, Feb 29, 2008 at 6:41 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
Will you provide a patch for that, or should I? (I remind you I have no
box ready to reproduce it on, so it helps a lot if you can do it :-P)
Patch attached. Tested on XP and Vista.
--
Dave Page
EnterpriseDB UK Ltd:
On Tue, Mar 04, 2008 at 03:28:30PM +, Dave Page wrote:
On Fri, Feb 29, 2008 at 6:41 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
Will you provide a patch for that, or should I? (I remind you I have no
box ready to reproduce it on, so it helps a lot if you can do it :-P)
Patch
Hi,
attached is our patch against HEAD which enables extending CommandIds
to 64-bit. This is for enabling long transactions that really do that much
non-read-only work in one transaction.
The feature is off by default, you need to --enable-huge-commandid.
It fails only one regression test
Zoltan Boszormenyi wrote:
attached is our patch against HEAD which enables extending CommandIds
to 64-bit. This is for enabling long transactions that really do that much
non-read-only work in one transaction.
I think you should add a pg_control field and corresponding check, to
avoid a
Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
attached is our patch against HEAD which enables extending CommandIds
to 64-bit. This is for enabling long transactions that really do that much
non-read-only work in one transaction.
I think you should add a pg_control field and
Hello
I actualized sql/psm patch. This patch can be downloaded from
http://www.pgsql.cz/patches/plpgpsm.diff.gz
Documentation is on wiki http://www.pgsql.cz/index.php/SQL/PSM_Manual
Regards
Pavel Stehule
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to
Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
attached is our patch against HEAD which enables extending CommandIds
to 64-bit. This is for enabling long transactions that really do that much
non-read-only work in one transaction.
I think you should add a pg_control field and
Magnus Hagander wrote:
The patch only converts a couple of the potential enum variables to the new
type, mainly as a proof of concept. But already I hit the problem twice -
the variable that holds the value of the guc enum is a C enum itself, which
gives a compiler warning when I pass a pointer
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Heikki Linnakangas [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
On my platform (linux x86) it works fine when I just cast this to (int *),
but I'm unsure if that's going to be safe on other platforms. I had some
indication that it's probably not?
No, I don't think that's safe. Some
Bjorn Munch [EMAIL PROTECTED] writes:
The fix is simply to add -lgss to the list, as the attached patch
does. I'm pretty sure no other Makefiles are affected.
Applied, thanks.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To
16 matches
Mail list logo
