[BUGS] BUG #4010: psql does not honour -c after database name
The following bug has been logged online: Bug reference: 4010 Logged by: Jasen Betts Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.0 (win32) Operating system: XP pro Description:psql does not honour -c after database name Details: I notice psql is now enforcing the argument ordering that is documented in the --help blurb Is that considered a feature I used to do psql -U username database -c "some big long command" and that no longer works :( I guess this usage is going against the documented command-line format. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-bugs
[BUGS] BUG #4011: spelling mistake in comments
The following bug has been logged online: Bug reference: 4011 Logged by: Jasen Betts Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3 Operating system: WINDOWS xp Description:spelling mistake in comments Details: bin/psql.bat 11 s/exist/exits/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-bugs
Re: [BUGS] BUG #4010: psql does not honour -c after database name
Am Mittwoch, 5. März 2008 schrieb Jasen Betts: > I used to do > > psql -U username database -c "some big long command" > > and that no longer works :( Whether or not this works is determined by the operating system, not by PostgreSQL. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-bugs
Re: [BUGS] BUG #4011: spelling mistake in comments
On Wed, Mar 05, 2008 at 12:32:54AM +, Jasen Betts wrote: > > The following bug has been logged online: > > Bug reference: 4011 > Logged by: Jasen Betts > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.3 > Operating system: WINDOWS xp > Description:spelling mistake in comments > Details: > > bin/psql.bat > 11 s/exist/exits/ Thanks for the report, fix applied for 8.3.1. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-bugs
[BUGS]
Hi, if i put port 5432 is already in use.. What i have to do? I tried with 5433 but when im installing the program cant creat user account . Regards, SAM
Re: [BUGS]
samuel santa puche wrote: Hi, if i put port 5432 is already in use.. What i have to do? I tried with 5433 but when im installing the program cant creat user account . Regards, SAM Hola, que version de postgres que S.O. que tenes "corriendo" en el puerto 5432? Saludos Fernando -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-bugs
Re: [BUGS] LISTEN/NOTIFY race condition?
Tom Lane wrote: Laurent Birtz <[EMAIL PROTECTED]> writes: From the observed sequence of events, it would appear that the event thread inserts a tuple in the pg_listener table BEFORE the command thread actually commits the transaction. However, when this transaction commits, Postgres does not actually find the event thread's tuple in this table. I'm wondering exactly when you commit the LISTEN? The command thread can't see the pg_listener tuple until it's committed ... I'm executing the LISTEN statement outside a transaction block. I presume Postgres implicitly adds the BEGIN and COMMIT statements in that case? Just to be clear, the SELECT statement that retrieve new events is also executed outside a transaction block. Thanks for the help, Laurent Birtz -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-bugs
[BUGS] Tom Belich
Hi Tom, If you are the Tom Belich I knew from SKCC please contact me. I lost your Christmas card from '06 with your phone number on it. Joe Kennedy, MD 858 459 8044 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-bugs
[BUGS] BUG #4012: bug in pg_query
The following bug has been logged online: Bug reference: 4012 Logged by: Renato Gravino Neto Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.3 Operating system: Linux 2.6.24.3 Description:bug in pg_query Details: in pg_query($con,'select * from cliente where age >= 10;'); translate to select * from cliente where age >= 10 but not execute query -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-bugs
Re: [BUGS] BUG #4012: bug in pg_query
In response to "Renato Gravino Neto" <[EMAIL PROTECTED]>: > > The following bug has been logged online: > > Bug reference: 4012 > Logged by: Renato Gravino Neto > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.2.3 > Operating system: Linux 2.6.24.3 > Description:bug in pg_query > Details: > > in pg_query($con,'select * from cliente where age >= 10;'); > translate to select * from cliente where age >= 10 > > but not execute query It looks like you're using PHP. I doubt this is a bug in pg_query() (as I'm using it heavily without problem) but I suspect it's a bug somewhere else in your code that's mangling the query string prior to giving it to pg_query(). Please describe the version of PHP you're using, as well as provide a complete example of code that reproduces the problem. I suspect that the command pg_query($con,'select * from cliente where age >= 10;'); is what you're actually executing. I suspect it's something more like pg_query($con, $querystring); and that the actual problem is that $querystring is already broken before you give it to pg_query(). In any event, it's unlikely that this is a bug in PostgreSQL. If you can provide a reproducible test case, it's probably a bug in PHP. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-bugs
[BUGS] BUG #4015: uninitialized value passed as an argument to tm2timetz
The following bug has been logged online:
Bug reference: 4015
Logged by: Ted Kremenek
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.0
Operating system: Mac OS X 10.5.2
Description:uninitialized value passed as an argument to tm2timetz
Details:
It appears that there may be a case where the function tm2timetz is called
with an uninitialized (i.e., undefined) value passed as one of its arguments
(actually multiple arguments are undefined). This appears to occur along an
error path when the date string is not properly formatted. I'm not certain
if this would be a real bug in practice, but it looks like a classic case
where an input processing function fails to properly recover from malformed
input.
Here is the code and diagnosis.
In postgresql-8.3.0/src/backend/utils/adt/date.c:
Datum
timetz_in(PG_FUNCTION_ARGS)
{
...
int tz;
...
dterr = ParseDateTime(str, workbuf, sizeof(workbuf),
field, ftype, MAXDATEFIELDS,
&nf);
==> In the case ParseDateTime fails, dterr has a non-zero value.
if (dterr == 0) {
==> This branch is NOT taken.
==> This is the only branch that initializes "tz" by passing it
==> by reference to DecodeTimeOnly. Note that the struct
==> referred to by tm is also not initialized.
dterr = DecodeTimeOnly(field, ftype, nf, &dtype, tm, &fsec, &tz);
}
if (dterr != 0) {
==> This branch is TAKEN.
==> Note that "tz" is not initialized, nor does
==> DateTimeParseError cause execution to abort.
DateTimeParseError(dterr, str, "time with time zone");
}
result = (TimeTzADT *) palloc(sizeof(TimeTzADT));
==> ERROR:
==> At this point "tz" is passed to tm2timetz, which is uninitialized.
==> Note that the value pointed to be "tm" is also uninitialized,
==> meaning that tm2timetz is passed garbage that sometimes
==> may be valid (due to remnants of data still on the stack).
tm2timetz(tm, fsec, tz, result);
AdjustTimeForTypmod(&(result->time), typmod);
PG_RETURN_TIMETZADT_P(result);
}
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-bugs
Re: [BUGS] BUG #4015: uninitialized value passed as an argument to tm2timetz
"Ted Kremenek" <[EMAIL PROTECTED]> writes: > It appears that there may be a case where the function tm2timetz is called > with an uninitialized (i.e., undefined) value passed as one of its arguments > (actually multiple arguments are undefined). I think you're assuming DateTimeParseError() will return, which it will not (it always throws ereport(ERROR)). Or have I missed something? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-bugs
