[BUGS] BUG #2875: pgAdmin III docs installed even if app is not
The following bug has been logged online: Bug reference: 2875 Logged by: Kevin Macdonald Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.1 Operating system: Windows XP Description:pgAdmin III docs installed even if app is not Details: The the documentation for pgAdmin III was installed eventhough the product itself was deselected to not be installed. File: ./PostgreSQL/8.2/pgAdmin III/docs/en_US/ pgadmin3.chm ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2870: incorrect man page for postgres
Tom, On Wed, Jan 03, 2007 at 08:02:34PM -0500, Tom Lane wrote: > No, Dmitry has it right: the man page is mistaken. You can still get > silent mode but you have to use the long-form option (--silent-mode=1). > > I've corrected the documentation error in CVS. I think that you have forgotten to regenerate man pages from SGML since 8.2.1 is out and postgresql-base-8.2.1.tar.bz2 contains the old man page for postgres(1). -- (GM) ---(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 #2875: pgAdmin III docs installed even if app is not
Kevin Macdonald wrote: > The following bug has been logged online: > > Bug reference: 2875 > Logged by: Kevin Macdonald > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.2.1 > Operating system: Windows XP > Description:pgAdmin III docs installed even if app is not > Details: > > The the documentation for pgAdmin III was installed eventhough the product > itself was deselected to not be installed. > > File: ./PostgreSQL/8.2/pgAdmin III/docs/en_US/ pgadmin3.chm Right. That is by design. The pgAdmin documentation contains the PostgreSQL documentation. In order to avoid installing two copies of the documentation, the pgAdmin version will always be installed. This version is also in a compiled CHM format which makes it easier to browse. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #2875: pgAdmin III docs installed even if app is not
> --- Original Message --- > From: "Kevin Macdonald" <[EMAIL PROTECTED]> > To: pgsql-bugs@postgresql.org > Sent: 1/8/07, 6:52:43 PM > Subject: [BUGS] BUG #2875: pgAdmin III docs installed even if app is not > > The following bug has been logged online: > > Bug reference: 2875 > Logged by: Kevin Macdonald > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.2.1 > Operating system: Windows XP > Description:pgAdmin III docs installed even if app is not > Details: > > The the documentation for pgAdmin III was installed eventhough the product > itself was deselected to not be installed. > > File: ./PostgreSQL/8.2/pgAdmin III/docs/en_US/ pgadmin3.chm That is by design - the PostgreSQL and Slony docs are in the same file. Regards, Dave ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [BUGS] BUG #2873: Function that returns an empty set with a 'not null' domain errors in 8.2 but not 8.1
On Mon, Jan 08, 2007 at 10:27:15AM -0500, Tom Lane wrote: > "Jonathan Hull" <[EMAIL PROTECTED]> writes: > > The key feature for the error is that when a result structure (eg : pg_foo) > > is defined with a domain type that is not null, only PG 8.2 errors if the > > result is an empty set. > > The problem is explained well enough by this comment in plpgsql's code > for FOR-over-query: > > /* > * If the query didn't return any rows, set the target to NULL and return > * with FOUND = false. > */ > > At the time this code was written, there weren't any potential negative > side-effects of trying to set a row value to all NULLs, but now it's > possible that that fails because of domain constraints. > > I think the idea was to ensure that a record variable would have the > correct structure (matching the query output) post-loop, even if the > query produced zero rows. But it's not clear that that is really > useful for anything, given plpgsql's dearth of introspection facilities. > So we could make Jonathan's problem go away if we just take out the > assignment of nulls, and say that FOR over no rows leaves the record > variable unchanged. The documentation doesn't specify the current > behavior. > > Looking through the code, I see another place that does the same thing: > FETCH from a cursor, when the cursor has no more rows to return. It's > a bit harder to argue that it's sane to leave the variable unchanged > in this case. However, the documentation doesn't actually promise that > the target gets set to null in this case either. I think it would be safer to set the record variable to something that wipes any old data. I can't think of any examples of good code that would fall prey to this, but I can certainly think of some nasty bugs that users could inadvertently create. I know I'd personally like to have the safety net... Perhaps a means to mark the record as being null, other than setting all the fields to null? That might also allow for a means for users to set records to null, which I think would be useful in some cases. BTW, are row variables also affected by this bug or is it just record variables? -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(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: [HACKERS] [BUGS] BUG #2873: Function that returns an empty set with a 'not null' domain errors in 8.2 but not 8.1
"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > Perhaps a means to mark the record as being null, other than setting all > the fields to null? We could probably bypass the call of the domain input function, thereby avoiding the elog, but the point remains: if we do that, then we have a NOT-NULL-constrained domain variable that is reading out as NULL. One way or another we're going to be violating somebody's expectation. (BTW, I suspect that the case "DECLARE foo nonnulldomain;" already has this issue, as I think that code path just stores a null without any ceremony.) This is closely related to the discussion a couple weeks ago about how a LEFT JOIN could produce nulls in an output column that was labeled as having a non-null-domain type. We haven't figured out what is a sane behavior for that case, either. I'm beginning to think that domains constrained not null are just fundamentally a bad idea. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [BUGS] BUG #2873: Function that returns an empty set
Tom Lane wrote: > This is closely related to the discussion a couple weeks ago about how > a LEFT JOIN could produce nulls in an output column that was labeled as > having a non-null-domain type. We haven't figured out what is a sane > behavior for that case, either. I'm beginning to think that domains > constrained not null are just fundamentally a bad idea. > I think we just expect left joins to produce nulls regardless of constraints on the underlying cols, don't we? Concluding that not null in domains is bad seems a bit drastic. cheers andrew ---(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
