Bruce Momjian <[EMAIL PROTECTED]> writes:
> Mathieu Fenniak wrote:
>> I noticed that (SELECT E'\\' LIKE E'\\') returns false,
> I believe this is caused because backslash is the default escape
> character for LIKE, so you need:
> test=> SELECT E'\\' LIKE E'';
Yeah. The given case is ac
"Chris Barnes" <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] ~]$ /opt/PostgreSQL/8.3/bin/pg_ctl -w start -D
> \"/data/pgsql/data/\" -l \"/data/pgsql/data//pg_log/startup.log\"
Those backslashes don't look like a good idea: the quotes are ending
up as part of the file names.
Mathieu Fenniak wrote:
>
> The following bug has been logged online:
>
> Bug reference: 4436
> Logged by: Mathieu Fenniak
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.3.3
> Operating system: Linux x86-64
> Description:(E'\\' LIKE E'\\') => f
> Details:
The following bug has been logged online:
Bug reference: 4436
Logged by: Mathieu Fenniak
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.3
Operating system: Linux x86-64
Description:(E'\\' LIKE E'\\') => f
Details:
I noticed that (SELECT E'\\' LIKE E'\\') r
This was working, restarted to put (custom_variable_classes = 'olap' ) in
conf file.
Restarted but no errors in the startup.log or command line
[EMAIL PROTECTED] ~]$ /opt/PostgreSQL/8.3/bin/pg_ctl -w start -D
\"/data/pgsql/data/\" -l \"/data/pgsql/data//pg_log/startup.log\"
I am using
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It looks like the parser's code path for multi-row VALUES is neglecting
>> to detect sublinks and set pstate->p_hasSubLinks. I'm too tired to look
>> closer tonight; anyone want to poke into it?
> I think the parser is OK, but th
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>>> The point being that the config files are opened with AllocateFile(),
>>> which in turn calls fopen(). It doesn't use open(). The proposal was
>>> only to make all *open()* calls do it binary. I was under the impression
>>> that on Unix, that's what
Tom Lane wrote:
The point being that the config files are opened with AllocateFile(),
which in turn calls fopen(). It doesn't use open(). The proposal was
only to make all *open()* calls do it binary. I was under the impression
that on Unix, that's what open() did, so we should behave the same?
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> Tom Lane wrote:
>>> If you need a positive reason why this might be a bad idea, consider the
>>> idea that someone is examining postgresql.conf with a text editor that
>>> stops reading at control-Z. He might not be able to see
Magnus Hagander wrote:
> Andrew Dunstan wrote:
>>
>> Tom Lane wrote:
>>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>>>
Tom Lane wrote:
> Well, why is that a bug? If the platform is so silly as to define text
> files that way, who are we to argue?
>
>>>
The
On Tue, Sep 23, 2008 at 10:38 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Dean Rasheed" <[EMAIL PROTECTED]> writes:
>> CREATE TABLE foo(a int, b int);
>> CREATE VIEW foo_v AS SELECT * FROM foo;
>> CREATE RULE foo_r AS ON INSERT TO foo_v DO INSTEAD INSERT INTO foo
>> VALUES(NEW.a, NEW.b);
>> INSERT I
Tom Lane wrote:
"Dean Rasheed" <[EMAIL PROTECTED]> writes:
CREATE TABLE foo(a int, b int);
CREATE VIEW foo_v AS SELECT * FROM foo;
CREATE RULE foo_r AS ON INSERT TO foo_v DO INSTEAD INSERT INTO foo
VALUES(NEW.a, NEW.b);
INSERT INTO foo_v VALUES ((SELECT 1), (SELECT 2)), ((SELECT 3), (SELECT 4));
12 matches
Mail list logo
