On Wed, Apr 13, 2011 at 8:18 PM, Heikki Linnakangas
wrote:
> Yep :-(. I'm thinking we need to revert that change, now that we know there
> was a reason for only checking the end-of-WAL when doing archive recovery
> after all. We can keep it as a warning, though. With a hint explaining that
> if yo
"Kevin Grittner" writes:
> I'm not sure the spec requires *any* of them to work.
It doesn't. NULL in the standard is not part of the generic expression
syntax; it only appears as (which
lets it be the direct argument of CAST, or the DEFAULT value for a table
column) and as (which lets it
be an
"Kevin Grittner" writes:
> Tom Lane wrote:
>> The sticking point is just that in purely syntactic terms this is
>> action-at-a-distance, and so it's hard to square with the spec. I
>> think that our current reading (in which the '1' and '2' get
>> resolved as text) is actually closer to what the
Tom Lane wrote:
> so far as I can see the spec simply disallows a
> not-explicitly-cast NULL constant in cases like this, which seems
> if anything even less friendly than what we're doing.
Just to illustrate the current behavior:
test=# select null union select 1;
?column?
--
Tom Lane wrote:
> you wish that in
>
> (select '1' union select '2') union select 3
>
> the fact that the third value is clearly integer would influence
> the choice of the resolved type of the first UNION.
Yeah.
> My vision of how to implement that is different than what you seem
>
"Paul Deschamps" writes:
> PostgreSQL version: 8.4.6
> Operating system: Ubuntu 10.4
> Description:Running postgress in a shell script fails
> Details:
> When running postgres in a shell using the -c option it looks as though it
> parses the contents of the --command as command line ar
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Consider
>>
>> select '1' union select '1 ';
>>
>> How many rows does that produce? You cannot answer without
>> imputing a data type to the columns. "text" will give a different
>> answer than "integer" or "bpchar".
> Well, if we were to assign
Tom Lane wrote:
> Consider
>
> select '1' union select '1 ';
>
> How many rows does that produce? You cannot answer without
> imputing a data type to the columns. "text" will give a different
> answer than "integer" or "bpchar".
Well, if we were to assign both to type unknown initially
The following bug has been logged online:
Bug reference: 5978
Logged by: Paul Deschamps
Email address: pdescha...@gmail.com
PostgreSQL version: 8.4.6
Operating system: Ubuntu 10.4
Description:Running postgress in a shell script fails
Details:
When running postgres i
"Kevin Grittner" writes:
> From my perspective the "right" answer is to be able to resolve two
> unknown types to unknown rather than text in a few places where we
> are currently compelled to assign a concrete type.
Well, it's not so easy as that. Consider
select '1' union select '1 ';
Tom Lane wrote:
> The reason we haven't done it is that it looks like the SQL
> standard requires type resolution for set-ops to happen one pair
> of input relations at a time.
Well, it also requires that an unadorned quoted literal is of type
char(n). This is inextricably tied in with the Po
On 13.04.2011 14:18, Heikki Linnakangas wrote:
On 13.04.2011 10:49, hubert depesz lubaczewski wrote:
hi
got new 9.1, straight from git.
compiled, installed.
did initdb, and then set config values using this script:
perl -pi -e '
s/\A \s* (?: [#] \s* )? listen_addresses \s* = \s*.*/listen_address
"Jeff Wu" writes:
> The UNION construct (as noted on this page:
> http://www.postgresql.org/docs/9.0/static/typeconv-union-case.html) will
> cast unknown types to TEXT, however, if you try to do three or more UNIONs
> the order in which the UNIONs are executed will cause some columns to be
> cast
"John Dickson" writes:
> The following SQL (executed on 8.3.11) shows a result one higher than the
> maximum permissible remainder when combined with a cast:
> select 1129590 % 66,
> cast(1129590 as numeric(21, 0)) % 66;
> ?column? | ?column?
> --+--
> 0 | 66
Th
Tim Wallace writes:
> Version: 9.0.3
> after successful configure, make fails if you have the env var "U" set.
> It fails almost immediately in the src/port directory with a
> nonsensical error message involving the contents of the "U" var. Unset
> U and everything built fine.
So far as I c
Version: 9.0.3
after successful configure, make fails if you have the env var "U" set.
It fails almost immediately in the src/port directory with a
nonsensical error message involving the contents of the "U" var. Unset
U and everything built fine.
--Tim Wallace
--
Sent via pgsql-bugs mail
"Anton Kuznetsov" writes:
> Server crases on delete and than automatically restarts;
> Log message was:
> TRAP: FailesAssertion("!(outerstartsel <= outerendsel)", File:
> "costsize.c", String: 1540)
That's pretty interesting ... can you put together a self-contained test
case? That might be a
The following bug has been logged online:
Bug reference: 5977
Logged by: Anton Kuznetsov
Email address: antosh...@mail.ru
PostgreSQL version: 8.3.1
Operating system: Linux 2.4.32
Description:Crash on delete
Details:
Server crases on delete and than automatically res
On Wed, Apr 13, 2011 at 12:29 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> I think you may have uncovered a leak (I stand corrected).
>
>> The number of schemas in your test is irrelevant -- the leak is
>> happening in proportion to the number of views (set via \setrandom
>> tidx 1 10). At 1
13.04.2011 20:48, Kevin Grittner wrote:
"Vlad Arkhipov" wrote:
PostgreSQL version: 9.0.3
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: could not access status
of transaction 3499806839
DETAIL: Could not open file "pg_clog/0D09": No such file or
directo
"Vlad Arkhipov" wrote:
> PostgreSQL version: 9.0.3
> pg_dump: SQL command failed
> pg_dump: Error message from server: ERROR: could not access status
> of transaction 3499806839
> DETAIL: Could not open file "pg_clog/0D09": No such file or
> directory.
Did you get to 9.0 using pg_upgrade?
On 13.04.2011 10:49, hubert depesz lubaczewski wrote:
hi
got new 9.1, straight from git.
compiled, installed.
did initdb, and then set config values using this script:
perl -pi -e '
s/\A \s* (?: [#] \s* )? listen_addresses \s* = \s*.*/listen_addresses =
\047*\047/x;
s/\A \s* (?: [#] \s* )?
From: "Oliver Jowett"
If the server is shut down mid-query, doesn't the backend complete the
current query cycle before closing the connection?
i.e. we'd see ErrorResponse, ReadyForQuery, and return control to the
app before seeing EOF anyway?
The protocol spec is a bit vague there.
From an o
hi
got new 9.1, straight from git.
compiled, installed.
did initdb, and then set config values using this script:
perl -pi -e '
s/\A \s* (?: [#] \s* )? listen_addresses \s* = \s*.*/listen_addresses =
\047*\047/x;
s/\A \s* (?: [#] \s* )? log_destination \s* = \s*.*/log_destination =
\047stderr
24 matches
Mail list logo
