The following bug has been logged online:
Bug reference: 5104
Logged by: Herve LEFEBVRE
Email address: herve.lefeb...@bull.net
PostgreSQL version: 8.3.8
Operating system: Linux Ubuntu 9.04
Description:tsearch parser mislead
Details:
The french opening and closing qu
The following bug has been logged online:
Bug reference: 5102
Logged by: Geoff Tolley
Email address: geoff.tol...@yougov.com
PostgreSQL version: 8.3.8
Operating system: Ubuntu 8.04 x86_64
Description:Silent IN (list of strings) failure to detect syntax
error when list
The following bug has been logged online:
Bug reference: 5105
Logged by: Walter Mesz
Email address: meszwal...@yahoo.de
PostgreSQL version: 8.4.0
Operating system: Windows XP SP2
Description:"Select Into Strict" does not throw NO_DATA_FOUND
Details:
Hi,
my problem
Geoff Tolley wrote:
> postgres=# SELECT 'hello' WHERE '1' IN ('1' '2');
> ERROR: syntax error at or near "'2'"
> LINE 1: SELECT 'hello' WHERE '1' IN ('1' '2');
> ^
> postgres=# SELECT 'hello' WHERE '1' IN ('1'
> postgres(# '2');
> ?column?
> --
>
Alvaro Herrera wrote:
> alvherre=# select 'a'
> alvherre-# 'b';
> ?column?
> --
> ab
> (1 fila)
Ah, yes -- saith scan.l:
/*
* SQL requires at least one newline in the whitespace separating
* string literals that are to be concatenated. Silly, but who are we
* to argue? Note that
"Geoff Tolley" wrote:
> postgres=# SELECT 'hello' WHERE '1' IN ('1'
> postgres(# '2');
Per the SQL standard, that is the same as
SELECT 'hello' WHERE '1' IN ('12');
I believe that's intended to make it easier to code long string
literals without creating query text which has long line len
"Herve LEFEBVRE" writes:
> The french opening and closing quotes ( char iso 00AB and 00BB ) are
> considered by the parser as alpha chars rather than punctuation chars (and
> so as space symbol).
That would suggest that you're using the wrong locale setting.
You did not say what you're using, tho
Alvaro Herrera writes:
> I don't know much about this oddity but my first guess is that it's
> mandated by the SQL standard.
Yeah. The spec defines that you can split a literal across lines this
way. Notable quotes from SQL92:
::= { | | }...
1) In a or , the sequence:
"Walter Mesz" writes:
> my problem is that this select into does not throw a NO_DATA_FOUND if my
> select involves a max().
Well, a query using max() (or any other aggregate) is defined to return
exactly one row, independently of how many rows feed into the max().
So I'm not sure why you'd think
"Walter Mesz" wrote:
> my problem is that this select into does not throw a NO_DATA_FOUND
> if my select involves a max(). I did not see this behaviour
> documented anywhere and could not find it in a reasonable time at
> google.
> SELECT max(tanum)
>INTO STRICT x
>FRO
... Actually, I just noticed that there *is* a bug here:
regression=# select '1' /* foo
regression*# */
regression-# '2';
ERROR: syntax error at or near "'2'"
LINE 3: '2';
^
regression=#
The above should be accepted, but it isn't. I think the problem is
here:
special_whitespace
Hi
I've noticed that executing a sql script such with psql with -1
-vON_ERROR_STOP=on where the script causes a deferred foreign key
constraint to be violated returns 0 rather than the expected 3. I have
reproduced this in psql 8.4.1, 8.3.3 and 8.2.9, which does lead me to
wonder whether it i
Tom Lane wrote:
> ... Actually, I just noticed that there *is* a bug here:
>
> regression=# select '1' /* foo
> regression*# */
> regression-# '2';
> ERROR: syntax error at or near "'2'"
> LINE 3: '2';
> ^
> regression=#
>
> The above should be accepted, but it isn't.
It works with
I wrote:
> Shouldn't that be
> special_whitespace({space}+|{comment}|{newline})
No, scratch that ... {comment} is the -- form of comment and the newline
is to terminate the comment.
The actual issue here seems to be that the whitespace productions only
deal with the -- form of comment
Tom Lane wrote:
My current feeling about it is that setting unix_socket_directory as a
configuration parameter is only useful to those who are deliberately
trying to hide their postmaster from regular clients, in which case
the fact that pg_ctl -w fails could be seen as a feature not a bug.
The
Michael Renner wrote:
> Mentioning PGHOST in pg_ctl's
> manpage/documentation should make this entirely clear for people who
> aren't familiar with the extensive environment variables PostgreSQLs
> client library can use. [1]
Yeah, this has been complained about many, many times.
> If this is a
Alvaro Herrera wrote:
Michael Renner wrote:
Mentioning PGHOST in pg_ctl's
manpage/documentation should make this entirely clear for people who
aren't familiar with the extensive environment variables PostgreSQLs
client library can use. [1]
Yeah, this has been complained about many, many times
Sachin, thanks. Can you send me the installer for OS 64 Bit?
Best Regards.
Federico Aguirre
2009/10/6 Sachin Srivastava
> Hello Federico,
>
> Please use the apachephp installer from the following link:
>
> http://uploads.enterprisedb.com/download.php?file=9746ddac3a0d7be86a6b52ccf280e31f
>
>
18 matches
Mail list logo
