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, Formatio
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_wa
[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.]
"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
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 does
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 w
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. T
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 moddateti
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:
...
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. T
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 effect
"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
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
13 matches
Mail list logo
