On Nov 4, 2009, at 5:34 PM, Tom Lane wrote:
According to
http://developer.postgresql.org/pgdocs/postgres/plpgsql-declarations.html#PLPGSQL-DECLARATION-RENAMING-VARS
the RENAME declaration in plpgsql has been known broken since PG 7.3.
Nobody has bothered to fix it. Shall we just rip it out?
+
According to
http://developer.postgresql.org/pgdocs/postgres/plpgsql-declarations.html#PLPGSQL-DECLARATION-RENAMING-VARS
the RENAME declaration in plpgsql has been known broken since PG 7.3.
Nobody has bothered to fix it. Shall we just rip it out?
The reason I'm looking at it right now is that it
Tom Lane wrote:
> Thom Brown writes:
>> 2009/11/4 Alvaro Herrera :
>>> KaiGai Kohei wrote:
I think we should not allow to rename a column with attinhcount > 1.
>
>>> I think we should fix ALTER TABLE to cope with multiple inheritance.
>
>> I'd be interested to see how this should work.
>
>
> Recently, the development of SR is not progressing because of
> the indecision on whether walreceiver should be a subprocess
> of the startup process (i.e., a stand-alone program), or of
> postmaster. Since time is running out, I'd like to discuss
> about this and advance the project.
>
> The re
Heikki Linnakangas writes:
> ... But pointing to ESCAPE is just weird.
I've changed these all to @2 (LIKE, ILIKE, SIMILAR TO).
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgr
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> ... For the moment I've worked
> >> around this by putting the typedef into nodes/params.h itself, but I
> >> can't say I find that a pleasing solution. Has anyone got a better
> >> idea? Should we make a parser/something header
Hello everyone,
I was quite intrigued by a discussion that happened this past summer
regarding generation of bootstrap files such as postgres.bki, and the
associated pain points of maintaining the DATA() statements in catalog headers.
It occurred to me that the current system is backwards: Instead
Alvaro Herrera writes:
> What I thought could have happened is that the table was truncated, and
> then the sinval message telling that to other backends was not sent due
> to the rollback.
Hmm.
> So far as I can see, what we need is to make sure the sinval message is
> sent regardless of transa
Alvaro Herrera writes:
> Tom Lane wrote:
>> ... For the moment I've worked
>> around this by putting the typedef into nodes/params.h itself, but I
>> can't say I find that a pleasing solution. Has anyone got a better
>> idea? Should we make a parser/something header that just provides that
>> t
A customer of ours recently hit a problem where after an autovacuum was
cancelled on a table, the app started getting the message in $subject:
ERROR: could not read block 6 of relation 1663/35078/1761966: read only 0 of
8192 bytes
(block numbers vary from 1 to 6). Things remained in this state
--On 4. November 2009 09:57:27 -0500 Tom Lane wrote:
I think the
consensus was that the way to fix this (along with some other problems)
is to start representing NOT NULL constraints in pg_constraint, turning
attnotnull into just a bit of denormalization for performance.
Ah okay, should hav
On Wed, 2009-11-04 at 12:08 -0500, Chris Browne wrote:
> I'm
> a lot less certain about the merits of PK/FK constraints - it is a lot
> less obvious what forms of constraints will be able to be applied to
> particular applications.
Can you clarify, a little?
A temporal key just means "non-overlap
arta...@comcast.net (Scott Bailey) writes:
> Disk format - A period can be represented as [closed-closed],
> (open-open), [closed-open) or (open-closed] intervals. Right now we
> convert these to the most common form, closed-open and store as two
> timestamptz's.
I mentioned this at the 2009 PGCon
On Tue, Nov 3, 2009 at 6:31 AM, Peter Eisentraut wrote:
>
> Is anyone planning to do further work on this? This appears to be
> blocking the client_encoding=auto feature.
>
yes, i'm planning to make an attempt to do it as soon as i get some
time... but if you think it's important enough please g
Tom Lane wrote:
> It turns out that this typedef is needed in two relatively low-level
> .h files: nodes/params.h and utils/plancache.h. My original idea had
> been to define the hook typedef in parser/parse_node.h where struct
> ParseState is defined. But that would have required pulling a boat
On ons, 2009-11-04 at 09:44 -0500, Robert Haas wrote:
> On Wed, Nov 4, 2009 at 9:02 AM, Peter Eisentraut wrote:
> > Here is a patch to support arrays in PL/Python as parameters and return
> > values. It converts an array parameter to a Python "list", and converts
> > a Python "sequence" return va
Bernd Helmle writes:
> Consider the following workflow:
> CREATE TABLE foo(id integer NOT NULL, val text NOT NULL);
> CREATE TABLE foo2(another_id integer NOT NULL) INHERITS(foo);
> Now someone decides he doesn't want the NOT NULL constraint on the
> inherited column "val" anymore:
> ALTER TAB
On Wed, Nov 4, 2009 at 9:02 AM, Peter Eisentraut wrote:
> Here is a patch to support arrays in PL/Python as parameters and return
> values. It converts an array parameter to a Python "list", and converts
> a Python "sequence" return value back to an array.
This is probably a stupid question, but
Thom Brown writes:
> 2009/11/4 Alvaro Herrera :
>> KaiGai Kohei wrote:
>>> I think we should not allow to rename a column with attinhcount > 1.
>> I think we should fix ALTER TABLE to cope with multiple inheritance.
> I'd be interested to see how this should work.
Yeah. I don't think a "fix" i
I just run across an issue with ALTER TABLE and inheritance (i don't know
wether this is of the same kind of issue KaiGai reported today, so i keep
it on a separate thread).
Consider the following workflow:
CREATE TABLE foo(id integer NOT NULL, val text NOT NULL);
CREATE TABLE foo2(another_i
Here is a patch to support arrays in PL/Python as parameters and return
values. It converts an array parameter to a Python "list", and converts
a Python "sequence" return value back to an array.
I have settled on two implementation restrictions for the moment:
- Only supports one-dimensional arr
2009/11/4 Alvaro Herrera :
> KaiGai Kohei wrote:
>
>> postgres=# SELECT * FROM t2;
>> ERROR: could not find inherited attribute "b" of relation "t3"
>>
>> Because t3.b is also inherited from the t2, but ALTER TABLE does not
>> care about multiple inherited columns well.
>>
>> I think we should
Tom Lane wrote:
Greg Stark writes:
On Wed, Nov 4, 2009 at 3:17 AM, Emmanuel Cecchet wrote:
SELECT DISTINCT ON ('1'::varchar, '1'::varchar) a FROM (SELECT 1 AS a) AS a
ORDER BY '1'::varchar, '1'::varchar, '2'::varchar;
This sounds familiar. What version of Postgres are y
KaiGai Kohei wrote:
> postgres=# SELECT * FROM t2;
> ERROR: could not find inherited attribute "b" of relation "t3"
>
> Because t3.b is also inherited from the t2, but ALTER TABLE does not
> care about multiple inherited columns well.
>
> I think we should not allow to rename a column with
Fujii Masao wrote:
> On Wed, Aug 19, 2009 at 6:45 PM, Heikki Linnakangas
> wrote:
>> Is pg_standby killed correctly when postmaster dies?
>
> No. In my test (v8.3.7 on Win), an immediate shutdown was able to
> kill postmaster, but not pg_standby and the startup process.
Hmm. We should do somethi
Simon Riggs wrote:
> On Thu, 2009-10-15 at 13:18 +0900, Itagaki Takahiro wrote:
>> Simon Riggs wrote:
>>
Is it possible to use WAL-skipping and BulkInsertState in ATRewriteTable()
?
If ok, I'll submit a patch for the next commitfest.
>>> Yes
>> Patch attached.
>> This patch skip WA
Hi,
Sorry for this late reply.
On Wed, Aug 19, 2009 at 6:45 PM, Heikki Linnakangas
wrote:
> Is pg_standby killed correctly when postmaster dies?
No. In my test (v8.3.7 on Win), an immediate shutdown was able to
kill postmaster, but not pg_standby and the startup process.
Though we should chang
27 matches
Mail list logo
