This is the continuation to the discussion that we had in the
hacker's list.
http://archives.postgresql.org/pgsql-hackers/2007-08/msg00684.php
Here, I like to add some details in 20.2.6. PAM authentication section.
http://www.postgresql.org/docs/8.2/interactive/auth-methods.html#AUTH-PAM
Hi all,
This is the continuation to the discussion that we had in the hacker's
list.
http://archives.postgresql.org/pgsql-hackers/2007-08/msg00684.php
Here, I like to add some details in 20.2.6. PAM authentication section.
http://www.postgresql.org/docs/8.2/interactive/auth-methods.html#AUTH-
d be huge, and the gain quite small.
I'd rather see an HBA fallback mechanism, which I suspect might
overcome most of the problems being encountered here.
cheers
andrew
--
====
Dhanaraj M
x40049/+91-9880244950
Solaris RPE, Bangalore, India
ht
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Dhanaraj M wrote:
I am sending the patch for the following TODO item:
Allow the identifier length to be increased via a configure option
You should use pg_config.h, not mangle postgres_ext.h like that. Or
I am sending the patch for the following TODO item:
Allow the identifier length to be increased via a configure option
During the configuration time, the user can set the identifier length.
./configure.txt --with-identlen=128
However, I am not clear about the requirement.
Can somebody review and
Sorry for resubmitting this patch.
Just now I found a problem.
Instead of assigning initial sequence value to 1,
I assign LLONG_MAX to avoid the buffer overflow problem.
Please find the current version here.
Dhanaraj M wrote:
Hi all,
This patch was discussed a few months ago.
I could not
;1' initially
3. After executing the query, call AssignSeqValue()
4. This function assigns the respective sequence values back to the
resultset
Please review and comment on this patch.
Thanks
Dhanaraj
Tom Lane wrote:
Dhanaraj M <[EMAIL PROTECTED]> writes:
However, it was not p
Hi Alvaro
Thanks for your valuable suggestions.
I made the changes as suggested earlier.
Please review again and comment on this.
I like to make changes if it is required.
*** ./src/backend/commands/portalcmds.c.orig Sat Aug 12 23:04:54 2006
--- ./src/backend/commands/portalcmds.c Fri Aug 18 22:5
This patch is for the following TODO item.
SQL command:
-/Change LIMIT/OFFSET and FETCH/MOVE to use int8
/Since the limit/offset patch is already applied,
this patch is meant for Fetch/Move query.
I have tested the patch and it works for int64 values.
Please verify this.
Thanks
Dhanaraj
/
/
**
value, it is
appreciated.
Also, it gives the following error msg, when the input exceeds the int8
limit.
ERROR: bigint out of range
I attach the patch. Pl. check it.
Thanks
Dhanaraj
Tom Lane wrote:
Dhanaraj M <[EMAIL PROTECTED]> writes:
I attach the patch for the following TOD
limit.
ERROR: bigint out of range
I attach the patch. Pl. check it.
Thanks
Dhanaraj
Tom Lane wrote:
Dhanaraj M <[EMAIL PROTECTED]> writes:
I attach the patch for the following TODO item.
SQL COMMAND
* Change LIMIT/OFFSET to use int8
This can't possibly be correct.
I attach the patch for the following TODO item.
SQL COMMAND
* Change LIMIT/OFFSET to use int8
It passes all the regression tests and supports int8.
I am waiting for your review.
Thanks
Dhanaraj
*** ./src/backend/executor/nodeLimit.c.orig Sun Jun 25 15:02:46 2006
--- ./src/backend/execu
Bruce Momjian wrote:
Uh, I just added /contrib/adminpack a few weeks ago to CVS, which does
this, and more. Sorry I forgot to mark the TODO item as completed.
---
1. int8 pg_catalog.pg_file_read(fname text, data text
The patch is attached for the following TODO item:
*Allow server logs to be remotely read.
Steps:
1. When the server starts (**pg_ctl start)**, the path of the postmaster file is stored
2. The user can access the logfile using the following 2 functions:
* pg_file_readlog(int linenumber) -
Bruce Momjian wrote:
I am thinking we just add another column to the \d display for sequences
showing the current value.
---
As suggested in the previous mails, I tried to use the following to
display the seq. value.
Tom Lane wrote:
Dhanaraj M <[EMAIL PROTECTED]> writes:
sorry for sending the old version in the previous mail . Here I attach
the recent version of the patch file.
--
Surely this problem does not r
--- Begin Message ---
sorry for sending the old version in the previous mail . Here I attach
the recent version of the patch file.
Dhanaraj M wrote:
I saw the following in the TODO list.
clients-psql
1. Have psql show current values for a sequence
Hence, this patch displays
I saw the following in the TODO list.
clients-psql
1. Have psql show current values for a sequence
Hence, this patch displays the current seq. value in a separate column when \ds
is executed.
I attach the patch here. The display format may have to be changed. I would
like to chan
Hi
I send the appropriate patch for bug #2073. This fix disallows to change the
default sequence.
I ran the regression test and passed. The bug details are given below.
I am awaiting to answer for any further clarifications.
===
Hi
I attach the patch for this bug. I have run the regression test and
passed. please review this and waiting for your reply.
As explained in the mailing list, the parenthesis is appened when '|'
operator is used without parenthesis.
Thanks
Dhanaraj
be dropped and cant be changed. I like to send
you the appropriate patch and waiting for your reply.
Thanks
Dhanaraj
Tom Lane wrote:
Dhanaraj M - Sun Microsystems <[EMAIL PROTECTED]> writes:
I fixed the above bug. I attach the patch here. Please review and
acknowledge me.
Hi all
I fixed the above bug. I attach the patch here. Please review and
acknowledge me.
Bug details
BUG #2073: Can't drop sequence when created via SERIAL column
* From: "Aaron Dummer"
* To: pgsql-bugs ( at ) postgresql ( dot ) org
* Subject: BUG #2073: Can't drop sequence
22 matches
Mail list logo