Re: [BUGS] index on function confuses drop table cascade on child
Tom Lane writes: > Any thoughts out there? Color me slow, but I don't understand what allows an index creation on a table to not systematically add a dependency entry for the index that references the table. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] index on function confuses drop table cascade on child
Tom Lane wrote: > 3. Or, perhaps we could change recordDependencyOnSingleRelExpr so > that it generates a whole-table dependency on the target relation > even if there are no Vars in the expression. This would make it > act much more like the regular-query context that > find_expr_references_walker is expecting --- in essence, since > we're fabricating a single-element rtable for > find_expr_references_walker to work with, we should fabricate the > implied whole-table dependency entry too. But that seems a bit > weird too, and in particular it's not obvious whether to do that > if in fact the expression is empty, or doesn't contain any Var at > all. This one seems sensible *if* you assume that by the time it is called there is a known dependency on the particular relation -- for example, you are dealing with an index on that relation. Is that a reasonable restriction on the use of the recordDependencyOnSingleRelExpr function? If this was done, would it allow simplification of the index_create code you showed in #1? -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Fwd: ***SPAM*** Re: [BUGS] BUG #5739: postgresql will not start
[Forwarding to the list. Please keep the list copied; for one thing, there is likely to be someone there who has heard of Arch Linux or pacman, which I have not. This is more of a question regarding how the packagers for that distro intend for upgrades to occur, not a bug in PostgreSQL itself.] Dedanna wrote: I ran in Arch Linux, from the repos, pacman -Syu, and postgresql updated. That's all I know. I've successfully downgraded since, to: pacman -Q postgresql postgresql 8.4.4-6 The update initially was from regular updates. It was an update I didn't expect, btw - so just ran it and let it roll like any other. Loaded up Amarok1 in Arch, where I use it for my musicdb, and found that postgresql wasn't running that way. I tried to start it manually, tried rebooting, etc. - nothing worked. Kevin Grittner wrote: > "Kim Garren" wrote: > > >> Received update to postgresql 9.0.1-2 yesterday >> > > How? From where? What were you running before? > > >> Once booted, I try to start it manually, with the following >> result: >> >> # /etc/rc.d/postgresql start >> :: Starting PostgreSQL >> [BUSY] server starting >> >> [DONE] >> > > What is showing for `ps aux | grep postgres` ? What is in the > logs? > > >> https://bbs.archlinux.org/viewtopic.php?id=107656 >> > > >> https://bugs.archlinux.org/task/21560 >> > > Both of these make it sound like you were upgrading from > PostgreSQL > 8.4. This requires a database conversion. What technique did you > use for that? (The more specific you can be about the exact > steps, the more likely it is that someone will be able to help you.) > > >> I have lost my music db because of this. >> > > Not unless you deleted your data directory. If you don't back it > up regularly, it would certainly be wise to do so before a major > release upgrade. Making a recursive copy of the database data > directory would be a very good idea right now. > > -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] index on function confuses drop table cascade on child
"Kevin Grittner" writes: > Tom Lane wrote: >> 3. Or, perhaps we could change recordDependencyOnSingleRelExpr so >> that it generates a whole-table dependency on the target relation >> even if there are no Vars in the expression. This would make it >> act much more like the regular-query context that >> find_expr_references_walker is expecting --- in essence, since >> we're fabricating a single-element rtable for >> find_expr_references_walker to work with, we should fabricate the >> implied whole-table dependency entry too. But that seems a bit >> weird too, and in particular it's not obvious whether to do that >> if in fact the expression is empty, or doesn't contain any Var at >> all. > This one seems sensible *if* you assume that by the time it is > called there is a known dependency on the particular relation -- for > example, you are dealing with an index on that relation. Is that a > reasonable restriction on the use of the > recordDependencyOnSingleRelExpr function? If this was done, would > it allow simplification of the index_create code you showed in #1? Well, it doesn't really improve matters for the index_create code. What it basically accomplishes so far as that's concerned is to guarantee that there will be a (likely redundant) whole-table dependency; which we could equally well guarantee from the other end, a la my fix #1. After sleeping on it I'm pretty well convinced that fix #1 is the way to go; it's simple and gets rid of some code that was just trying to be too cute. If we had a clear example of some future use of recordDependencyOnSingleRelExpr that would require a different behavior for the expression-dependency-extraction code, I might want to change that code instead; but we don't. (Obviously some more comments around the dependency-extraction code will be a good idea in any case.) regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5741: syslog line length
The following bug has been logged online: Bug reference: 5741 Logged by: heasley Email address: h...@shrubbery.net PostgreSQL version: 8.4 Operating system: solaris Description:syslog line length Details: * Max string length to send to syslog(). Note that this doesn't count the * sequence-number prefix we add, and of course it doesn't count the prefix * added by syslog itself. On many implementations it seems that the hard * limit is approximately 2K bytes including both those prefixes. */ #ifndef PG_SYSLOG_LIMIT #define PG_SYSLOG_LIMIT 1024 #endif solaris' syslogd limits the line length to 1024, with a FQDN and it's silly "msg ID" quite a bit is dropped by syslogd. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] ecpg preprocessor regression in 9.0
On Mon, Nov 01, 2010 at 03:47:04PM +0200, Heikki Linnakangas wrote: > On closer look, it's quite obvious: the code added to > ECPGdump_a_type thinks that ECPGt_const is a variable type, and > tries to look up the variable. The straightforward fix is this: > ... > But I wonder if there is a better way to identify variable-kind of > ECPGttypes than list the ones that are not. There's some special > ECPGttypes still missing from the above if-test, like > ECPGt_NO_INDICATOR, but I'm not sure if they can ever be passed to > ECPGdump_a_type. Seems a bit fragile anyway. I agree. How about adding a macro definition explicitely checking for the real variable types? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] ecpg preprocessor regression in 9.0
On closer look, it's quite obvious: the code added to ECPGdump_a_type thinks that ECPGt_const is a variable type, and tries to look up the variable. The straightforward fix is this: ... But I wonder if there is a better way to identify variable-kind of ECPGttypes than list the ones that are not. There's some special ECPGttypes still missing from the above if-test, like ECPGt_NO_INDICATOR, but I'm not sure if they can ever be passed to ECPGdump_a_type. Seems a bit fragile anyway. I agree. How about adding a macro definition explicitely checking for the real variable types? Why not a function instead of a macro? You can set a breakpoint on a function if you need to debug. It seems unlikely that you would every see any measurable performance gain by writing a macro instead of a function. -- Korry -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5740: contrib/spi/moddatetime.c doesn't work with timezones.
The following bug has been logged online: Bug reference: 5740 Logged by: Dirk Heinrichs Email address: dirk.heinri...@altum.de PostgreSQL version: 8.4.5 Operating system: Linux Description:contrib/spi/moddatetime.c doesn't work with timezones. Details: The moddatetime function provided by this module only works on columns of type "timestamp without time zone". Would be nice if it could also provide an analogous function moddatetime_tz which provides the same functionality for columns of type "timestamp with time zone". Thanks... Dirk -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] ecpg preprocessor regression in 9.0
On 02.11.2010 19:39, Michael Meskes wrote: On Mon, Nov 01, 2010 at 03:47:04PM +0200, Heikki Linnakangas wrote: On closer look, it's quite obvious: the code added to ECPGdump_a_type thinks that ECPGt_const is a variable type, and tries to look up the variable. The straightforward fix is this: ... But I wonder if there is a better way to identify variable-kind of ECPGttypes than list the ones that are not. There's some special ECPGttypes still missing from the above if-test, like ECPGt_NO_INDICATOR, but I'm not sure if they can ever be passed to ECPGdump_a_type. Seems a bit fragile anyway. I agree. How about adding a macro definition explicitely checking for the real variable types? You'd still have to list them all in the macro, but it would definitely be better. The list would then be closer to the enums, in the same header file, making it easier to remember to keep it up-to-date. (Korry's suggestion of making it a function instead of a macro would not have that advantage). -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] ecpg preprocessor regression in 9.0
On closer look, it's quite obvious: the code added to ECPGdump_a_type thinks that ECPGt_const is a variable type, and tries to look up the variable. The straightforward fix is this: ... But I wonder if there is a better way to identify variable-kind of ECPGttypes than list the ones that are not. There's some special ECPGttypes still missing from the above if-test, like ECPGt_NO_INDICATOR, but I'm not sure if they can ever be passed to ECPGdump_a_type. Seems a bit fragile anyway. I agree. How about adding a macro definition explicitely checking for the real variable types? You'd still have to list them all in the macro, but it would definitely be better. The list would then be closer to the enums, in the same header file, making it easier to remember to keep it up-to- date. (Korry's suggestion of making it a function instead of a macro would not have that advantage). Sure it would... use a switch statement that explicitly handles each type and include a default case that throws an error (or assertion). Of course, you have to run into the code to find out that you forgot to maintain the classification function. A good C compiler will even spot the problem if you forget to handle one or more enum values in the switch statement. A macro offers no assurances at all. -- Korry -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [PERFORM] typoed column name, but postgres didn't grump
Jon Nelson wrote: > If I saw this behavior ( a.b also meaning b(a) ) in another SQL > engine, I would consider it a thoroughly unintuitive wart I think the main reason it has been kept is the converse -- if you define a function "b" which takes record "a" as its only parameter, you have effectively created a "generated column" on any relation using record type "a". Kind of. It won't show up in the display of the relation's structure or in a SELECT *, and you can't use it in an unqualified reference; but you can use a.b to reference it, which can be convenient. It seems to me that this would be most useful in combination with the inheritance model of PostgreSQL (when used for modeling object hierarchies rather than partitioning). -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5740: contrib/spi/moddatetime.c doesn't work with timezones.
"Dirk Heinrichs" writes:
> The moddatetime function provided by this module only works on columns of
> type "timestamp without time zone". Would be nice if it could also provide
> an analogous function moddatetime_tz which provides the same functionality
> for columns of type "timestamp with time zone".
dim=# select pg_typeof('now'::timestamp), pg_typeof('now'::timestamptz);
pg_typeof |pg_typeof
-+--
timestamp without time zone | timestamp with time zone
(1 row)
So I guess that you need to modify very little code to get the trigger
to work for both types.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [PERFORM] typoed column name, but postgres didn't grump
On Tue, Nov 2, 2010 at 4:34 PM, Kevin Grittner wrote: > Jon Nelson wrote: > >> If I saw this behavior ( a.b also meaning b(a) ) in another SQL >> engine, I would consider it a thoroughly unintuitive wart > > I think the main reason it has been kept is the converse -- if you > define a function "b" which takes record "a" as its only parameter, > you have effectively created a "generated column" on any relation > using record type "a". Kind of. It won't show up in the display of > the relation's structure or in a SELECT *, and you can't use it in > an unqualified reference; but you can use a.b to reference it, which > can be convenient. Aha. I think I understand, now. I also read up on CAST behavior changes between 8.1 and 8.4 (what I'm using), and I found section 34.4.2 "SQL Functions on Composite Types" quite useful. Thanks! -- Jon -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
