On 22.02.2010 23:38, Bruce Momjian wrote:
Michael Renner wrote:
Looking through the available variables probably only PGHOST seems to be
of interest for pg_ctl's purposes; psql's manpage already refers to The
Documentation for further variables and information. What's needed in
pg_ctl's case
The following bug has been logged online:
Bug reference: 5342
Logged by: Shilpa.R
Email address: shilpar1...@gmail.com
PostgreSQL version: PostgreSQL Data
Operating system: Windows Xp
Description:Error
Details:
I found an error stating syntax error near or at sets
The following bug has been logged online:
Bug reference: 5343
Logged by: Rob Dean
Email address: rob.d...@pressassociation.com
PostgreSQL version: 8.3
Operating system: linux
Description:Documentation error for pg_dump
Details:
The last sentence of the penultimate
Shilpa.R shilpar1...@gmail.com wrote:
PostgreSQL version: PostgreSQL Data
That's not very informative; what do you get from running?:
select version();
I found an error stating syntax error near or at sets in the
following query
select agegrp, cartype, risk, count(*) as count
from
Shilpa.R escreveu:
select agegrp, cartype, risk, count(*) as count
from trset
group by risk, grouping sets ((agegrp,cartype))
This is not a bug. If you had searched the fine manual, you would figure out
that grouping sets is not supported by PostgreSQL yet.
--
Euler Taveira de Oliveira
Rob Dean rob.d...@pressassociation.com writes:
The information on reordering at restore time is surely completely
contradictory between the two. The 8.4 documentation is the same.
I'm sure that discrepancy goes way back :-(.
Some experimentation indicates that you can reorder some things but
Bruce Momjian br...@momjian.us wrote:
I think you should just edit the TODO wiki and list all the things
we agree need fixing:
Done, although with the wealth of opinions and dearth of agreement I
referenced much material and said that more discussion was needed
before starting development.
Rob Dean rob.d...@pressassociation.com writes:
The information on reordering at restore time is surely completely
contradictory between the two. The 8.4 documentation is the same.
Actually, on looking closer, I think the original author meant to draw a
distinction between database objects and
Alex Hunsaker bada...@gmail.com writes:
On Tue, Feb 23, 2010 at 00:50, Alex Hunsaker bada...@gmail.com wrote:
On Mon, Feb 22, 2010 at 14:31, Tom Lane t...@sss.pgh.pa.us wrote:
I'm inclined to stay with the same basic
implementation and just hack up the regexp some more to cope with 5.11's
On Mon, Feb 22, 2010 at 04:31:05PM -0500, Tom Lane wrote:
Alex Hunsaker bada...@gmail.com writes:
How about something like the below?
I still think that this is optimizing the wrong thing. We care about
the clarity of the message the user sees, not about how short or clean
the Perl code
Tim Bunce tim.bu...@pobox.com writes:
On Mon, Feb 22, 2010 at 04:31:05PM -0500, Tom Lane wrote:
I still think that this is optimizing the wrong thing. We care about
the clarity of the message the user sees, not about how short or clean
the Perl code is.
There's no need to try to parse the
On Tue, Feb 23, 2010 at 04:02:11PM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com writes:
On Mon, Feb 22, 2010 at 04:31:05PM -0500, Tom Lane wrote:
I still think that this is optimizing the wrong thing. We care about
the clarity of the message the user sees, not about how short or
[Resend. I misspelled the mailing list address on the original.]
David Wheeler has discovered a new PL/Perl failure when using Safe 2.2x.
It's not good.
In this email I'll try to explain the cause and some possible solutions.
PL/Perl compiles plperl functions inside a 'Safe compartment' which
The following bug has been logged online:
Bug reference: 5344
Logged by: Simon Ng
Email address: simon94...@yahoo.com
PostgreSQL version: 8.1.11
Operating system: RedHat Linux
Description:pg_restore some foreign keys missing
Details:
from server1 with Postgres
Pavel, all:
Apparently if you use one returns table function to call a 2nd returns
table function, it returns a recordset which consists entirely of nulls.
Here's the test case:
create table srf_data ( id serial, cat int, val text );
insert into srf_data ( cat, val ) values
( 1, 'josh' ),
( 1,
Josh Berkus j...@agliodbs.com writes:
Apparently if you use one returns table function to call a 2nd returns
table function, it returns a recordset which consists entirely of nulls.
In HEAD that example fails with
psql:josh.sql:30: ERROR: column reference id1 is ambiguous
LINE 1: select id1,
val1 is just as ambiguous. I think you got bit by the name collision;
the output parameters would start out NULLs and thus lead to the
described behavior, in versions before 9.0.
Aha, yeah, that's probably it. Take this example as the reason we had
to change the behavior ...
--Josh Berkus
On Tue, Feb 23, 2010 at 5:43 PM, Simon Ng simon94...@yahoo.com wrote:
The following bug has been logged online:
Bug reference: 5344
Logged by: Simon Ng
Email address: simon94...@yahoo.com
PostgreSQL version: 8.1.11
Operating system: RedHat Linux
Description:
2010/2/24 Josh Berkus j...@agliodbs.com:
Pavel, all:
Apparently if you use one returns table function to call a 2nd returns
table function, it returns a recordset which consists entirely of nulls.
Here's the test case:
create table srf_data ( id serial, cat int, val text );
insert into
2010/2/24 Josh Berkus j...@agliodbs.com:
val1 is just as ambiguous. I think you got bit by the name collision;
the output parameters would start out NULLs and thus lead to the
described behavior, in versions before 9.0.
Aha, yeah, that's probably it. Take this example as the reason we had
20 matches
Mail list logo
