On Tue, Jun 7, 2011 at 6:06 PM, Robert Haas wrote:
>> But for the planner, why not just put the same kind of test in
>> get_relation_info, just after it does heap_open?
>
> OK, let me try that.
Seems to work beautifully, so committed that way.
--
Robert Haas
EnterpriseDB: http://www.enterprised
Summary: \copy interprets psql's :variables as literal strings
Tested On: 8.4.4, 9.0.4
Severity: Annoyance
Steps to Reproduce:
psql
\set filename 'test.csv'
\copy pg_class to :filename with csv
\q
ls
:filename
Note that psql variables work p
On Tue, Jun 7, 2011 at 5:05 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jun 7, 2011 at 3:53 PM, Tom Lane wrote:
>>> It might be that it'd be best just to have both the planner and executor
>>> throwing errors on unlogged tables, rather than rejiggering pieces of
>>> the planner to sort-
Robert Haas writes:
> On Tue, Jun 7, 2011 at 3:53 PM, Tom Lane wrote:
>> It might be that it'd be best just to have both the planner and executor
>> throwing errors on unlogged tables, rather than rejiggering pieces of
>> the planner to sort-of not fail on an unlogged table.
> Mmm, that's not a
On Tue, Jun 7, 2011 at 3:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> I found a few other holes in my previous patch as well. I think this
>> plugs them all, but it's hard to be sure there aren't any other calls
>> to RelationGetNumberOfBlocks() that could bomb out.
>
> [ squint... ] Do we n
Greg Stark writes:
> A lot of work has gone into making pg_dump/pg_restore guarantee that
> they'll always produce a copy of the database, even if you've done odd
> things like change the lower bounds of your arrays. A lot of this was
> from before the days of PITR when pg_dump/pg_restore was the
Robert Haas writes:
> I found a few other holes in my previous patch as well. I think this
> plugs them all, but it's hard to be sure there aren't any other calls
> to RelationGetNumberOfBlocks() that could bomb out.
[ squint... ] Do we need those additional tests in plancat.c? I
haven't paid
On Tue, Jun 7, 2011 at 2:05 PM, Robert Haas wrote:
> On Tue, Jun 7, 2011 at 11:50 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> Patch along these lines attached.
>>
>> Frankly, I find this quite ugly, and much prefer the general approach of
>> your previous patch in .
>>
>> However, I don't lik
On Tue, Jun 7, 2011 at 11:41 AM, Tom Lane wrote:
> Robert Haas writes:
>> If your point here is that you don't want to spend time hacking on
>> this because it's a fairly marginal feature and therefore not terribly
>> high on your priority list, I can understand that. But if you're
>> actually d
On Sat, Jun 04, 2011 at 07:09:27AM +, dinesh wrote:
> I have a table which is used during data uploads, a so-called staging table.
> This table has a fixed number of columns that [must] match the input CSV
> file. This CSV file is uploaded using COPY command. Following the COPY, a
> new column
On Tue, Jun 7, 2011 at 11:50 AM, Tom Lane wrote:
> Robert Haas writes:
>> Patch along these lines attached.
>
> Frankly, I find this quite ugly, and much prefer the general approach of
> your previous patch in .
>
> However, I don't like where you put the execution-time test there. I'd
> put it
On Tuesday, June 07, 2011 04:29:02 Robert Haas wrote:
> On Fri, Jun 3, 2011 at 1:01 PM, Alvaro Herrera
>
> wrote:
> > Excerpts from Robert Haas's message of vie jun 03 12:44:45 -0400 2011:
> >> On Wed, Jun 1, 2011 at 2:28 PM, Robert Haas
wrote:
> >> > (4) It strikes me that it might be possible
Robert Haas writes:
> Patch along these lines attached.
Frankly, I find this quite ugly, and much prefer the general approach of
your previous patch in .
However, I don't like where you put the execution-time test there. I'd
put it in ExecOpenScanRelation instead, so that it covers both seqscan
But as a PostgreSQL user, I would like to had a warning when creating a view
with USING. It solves my problem. Maybe many others too.
2011/6/7 Robert Haas
> On Fri, Jun 3, 2011 at 2:21 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Fri, Jun 3, 2011 at 1:19 PM, Tom Lane wrote:
> >>> Now,
Robert Haas writes:
> If your point here is that you don't want to spend time hacking on
> this because it's a fairly marginal feature and therefore not terribly
> high on your priority list, I can understand that. But if you're
> actually defending the current implementation, I'm going to have t
Anton Dedov writes:
> We are using patched version of PostgreSQL 8.1 in order to work-around
> bug described in
> http://archives.postgresql.org/pgsql-bugs/2007-05/msg00130.php. Now, we
> are going to upgrade to 9.0 and it also would be great to get rid of
> patch as it makes keeping database
On Fri, Jun 3, 2011 at 2:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jun 3, 2011 at 1:19 PM, Tom Lane wrote:
>>> Now, if the query doesn't involve any explicit reference to "joinalias.*",
>>> we could probably fake it with some ugly thing involving
>>> COALESCE(leftcol, rightcol) ...
Alvaro Herrera writes:
> Excerpts from Robert Haas's message of mar jun 07 08:16:01 -0400 2011:
>> Probably. I guess the question is whether we want this to fail in (a)
>> the parser, (b) the planner, or (c) the executor.
> Really? I thought it was the job of the parse analysis phase to figure
Greg Stark writes:
> On Jun 3, 2011 4:20 PM, "Tom Lane" wrote:
>> I'm inclined to write this off as "so don't do that". There's nothing
>> that pg_dump can do to make this work: it has to use the USING syntax
>> for the join, and that doesn't offer any way to qualify the column name
>> on just o
Excerpts from Robert Haas's message of mar jun 07 08:16:01 -0400 2011:
> On Tue, Jun 7, 2011 at 2:57 AM, Simon Riggs wrote:
> > Seems like you're trying to fix the problem directly, which as you
> > say, has problems.
> >
> > At some point we resolve from a word mentioned in the FROM clause to a
>
The following bug has been logged online:
Bug reference: 6054
Logged by: Alex
Email address: alexander.ochkal...@gmail.com
PostgreSQL version: 8.4.8
Operating system: CentOS
Description:Insert to table, which has fkey to table,which is
parenttable for another table -
On Jun 3, 2011 4:20 PM, "Tom Lane" wrote:
>
> > [ view definition now fails due to multiple "id_a" columns ]
>
> I'm inclined to write this off as "so don't do that". There's nothing
> that pg_dump can do to make this work: it has to use the USING syntax
> for the join, and that doesn't offer any
Hello!
We are using patched version of PostgreSQL 8.1 in order to work-around
bug described in
http://archives.postgresql.org/pgsql-bugs/2007-05/msg00130.php. Now, we
are going to upgrade to 9.0 and it also would be great to get rid of
patch as it makes keeping database engine current too exp
On Tue, Jun 7, 2011 at 2:57 AM, Simon Riggs wrote:
> Seems like you're trying to fix the problem directly, which as you
> say, has problems.
>
> At some point we resolve from a word mentioned in the FROM clause to a
> relfilenode.
>
> Surely somewhere there we can notice its unlogged before we end
24 matches
Mail list logo
