The following bug has been logged online:
Bug reference: 6089
Logged by: Sidney Cadot
Email address: sid...@jigsaw.nl
PostgreSQL version: all
Operating system: all
Description:error in documentation: incorrect string literal for SSL
mode; 'disabled' vs 'disable'
Detai
The following bug has been logged online:
Bug reference: 6090
Logged by: zearth
Email address: napoh_ke...@hotmail.com
PostgreSQL version: 9
Operating system: Windows Server Standard SP2
Description:Connection problem
Details:
Cannot connect to routine server. Pleas
On Mon, Jul 4, 2011 at 16:30, Sidney Cadot wrote:
>
> The following bug has been logged online:
>
> Bug reference: 6089
> Logged by: Sidney Cadot
> Email address: sid...@jigsaw.nl
> PostgreSQL version: all
> Operating system: all
> Description: error in documentation: i
On 5/07/2011 9:35 AM, zearth wrote:
The following bug has been logged online:
Bug reference: 6090
Logged by: zearth
Email address: napoh_ke...@hotmail.com
PostgreSQL version: 9
Operating system: Windows Server Standard SP2
Description:Connection problem
Details:
Can
On Mon, Jul 4, 2011 at 12:02 PM, Tom Lane wrote:
> "Steve Haslam" writes:
>> ... Apparently, the data read from \copy
>> is incrementing the script line number counter?
>
> Yeah, so it is. That is correct behavior for COPY FROM STDIN,
> but not so much for copying from a separate file.
>
> The a
Hello.
System: PostgreSQL v9.0 Windows XP SP3
SQL: COPY "tablename" TO STDOUT WITH (FORMAT binary)
ERROR: syntax error at or near "binary"
LINE 1: ...OPY "tablename" TO STDOUT WITH (FORMAT binary)
^
** Error **
ERROR: syntax erro
Excerpts from Pavel Golub's message of mar jul 05 10:52:06 -0400 2011:
> Hello.
>
> System: PostgreSQL v9.0 Windows XP SP3
> SQL: COPY "tablename" TO STDOUT WITH (FORMAT binary)
> ERROR: syntax error at or near "binary"
> LINE 1: ...OPY "tablename" TO STDOUT WITH (FORMAT binary)
>
Hello, Alvaro.
You wrote:
AH> Excerpts from Pavel Golub's message of mar jul 05 10:52:06 -0400 2011:
>> Hello.
>>
>> System: PostgreSQL v9.0 Windows XP SP3
>> SQL: COPY "tablename" TO STDOUT WITH (FORMAT binary)
>> ERROR: syntax error at or near "binary"
>> LINE 1: ...OPY "tablename" TO STDOUT
On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera
wrote:
> Excerpts from Pavel Golub's message of mar jul 05 10:52:06 -0400 2011:
>> Hello.
>>
>> System: PostgreSQL v9.0 Windows XP SP3
>> SQL: COPY "tablename" TO STDOUT WITH (FORMAT binary)
>> ERROR: syntax error at or near "binary"
>> LINE 1: ...O
Robert Haas writes:
> On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera
> wrote:
>> I assume it's not in unreserved_keyword because it would cause a
>> shift/reduce conflict elsewhere.
> Yeah. In particular, it conflicts with the ancient copy syntax which
> we still support for backwards compatib
On 07/05/2011 11:23 AM, Robert Haas wrote:
Yeah. In particular, it conflicts with the ancient copy syntax which
we still support for backwards compatibility with versions< 7.3. We
can fix the immediate problem with something like the attached.
(a) Should we do that?
yes.
(b) Should we
On Tue, Jul 5, 2011 at 11:30 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera
>> wrote:
>>> I assume it's not in unreserved_keyword because it would cause a
>>> shift/reduce conflict elsewhere.
>
>> Yeah. In particular, it conflicts with the ancient c
Hello, Robert.
You wrote:
RH> On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera
RH> wrote:
>> Excerpts from Pavel Golub's message of mar jul 05 10:52:06 -0400 2011:
>>> Hello.
>>>
>>> System: PostgreSQL v9.0 Windows XP SP3
>>> SQL: COPY "tablename" TO STDOUT WITH (FORMAT binary)
>>> ERROR: syntax
On Tue, Jul 5, 2011 at 11:37 AM, Pavel Golub wrote:
> RH> Yeah. In particular, it conflicts with the ancient copy syntax which
> RH> we still support for backwards compatibility with versions < 7.3. We
> RH> can fix the immediate problem with something like the attached.
>
> This patch is ugly.
Robert Haas writes:
> ... However, if we don't do what I've proposed here,
> then I think 8.4 and 9.0 and probably 9.1 are going to need to stay as
> they are, because...
>> RH> (c) Should we consider removing compatibility with the ancient copy
>> RH> syntax in 9.2, and de-reserving that keyword
Hello, Robert.
You wrote:
RH> On Tue, Jul 5, 2011 at 11:37 AM, Pavel Golub wrote:
>> RH> Yeah. In particular, it conflicts with the ancient copy syntax which
>> RH> we still support for backwards compatibility with versions < 7.3. We
>> RH> can fix the immediate problem with something like the
On Sun, Jul 3, 2011 at 12:31 PM, Tom Lane wrote:
> Chris Bandy writes:
>> On Fri, Jul 1, 2011 at 10:35 PM, Tom Lane wrote:
>>> But AFAICS there is room for implementation dependency in other cases.
>>> In the particular cases you show here, PG recognizes some of them as
>>> being equivalent to n
Robert Haas writes:
> On Sun, Jul 3, 2011 at 12:31 PM, Tom Lane wrote:
>> The code that recognizes a default expression as being just constant
>> NULL doesn't think this is a constant NULL. In principle it could
>> recognize that, since the cast function is marked strict, but so far
>> it has no
On Tue, Jul 5, 2011 at 12:42 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Jul 3, 2011 at 12:31 PM, Tom Lane wrote:
>>> The code that recognizes a default expression as being just constant
>>> NULL doesn't think this is a constant NULL. In principle it could
>>> recognize that, since the
On Sat, 2011-07-02 at 18:38 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > On Sat, 2011-06-18 at 13:20 -0700, Jeff Davis wrote:
> >> Interesting problem... the bug is in get_op_btree_interpretation() which
> >> has code like this:
> >> ...
> >> However, that's a bogus test, because btree_gist put
Jeff Davis writes:
> I think that ripping out the change to btree_gist is also insufficient;
> we would also have to prevent other extensions from doing the same. That
> means documenting an odd special case, and testing for it when defining
> an opclass. And then we'd probably have to backpatch t
The following bug has been logged online:
Bug reference: 6092
Logged by: Jeff Frost
Email address: j...@pgexperts.com
PostgreSQL version: 9.0.4
Operating system: CentOS 5.5
Description:specific casting required for gist indexing of bigint
Details:
Ran into a situati
"Jeff Frost" writes:
> Ran into a situation with a customer who is using the btree_gist contrib
> module to allow combined index of some tsearch data and two other columns.
> One of these other columns is a bigint field. I noticed that the combined
> index won't be used by the planner unless you
23 matches
Mail list logo
