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
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 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
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 -
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
>
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
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
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) ...
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
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
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:
> 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
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
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 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: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 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
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
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
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
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 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-
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 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
24 matches
Mail list logo
