Is it an expected behavior?
postgres=# CREATE TABLE t1 (a int, b int);
CREATE TABLE
postgres=# CREATE TABLE t2 (b int, c int);
CREATE TABLE
postgres=# CREATE TABLE t3 (d int) inherits (t1, t2);
NOTICE: merging multiple inherited definitions of column "b"
CREATE TABLE
The t3.d is in
Tom Lane wrote:
> select nosuchfunction(1,2,3,avalidfunction(4));
>^
>
> select nosuchfunction(1,2,3,avalidfunction(4));
> ^
>
> Which of these is less likely to be misread about which function is
> being
Robert Haas wrote:
I'm not averse to EOL'ing 7.4, but I don't think it's fair to claim that
we already stopped supporting it.
Well, that would be overstating my position. We haven't stopped
supporting it, but there's less and less stuff that applies that far
back. I think it's better t
On Tue, Nov 3, 2009 at 12:13 PM, Simon Riggs wrote:
> On Tue, 2009-11-03 at 16:37 +, Dave Page wrote:
>> On Tue, Nov 3, 2009 at 4:29 PM, Simon Riggs wrote:
>>
>> > Unless there are unfixable data loss bugs in it, I say we keep it.
>> >
>> > Many people still run it, so why make them move?
>>
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 you testing this on?
Presumabl
On Tue, Nov 3, 2009 at 12:33 AM, Robert Haas wrote:
> On Mon, Nov 2, 2009 at 10:14 AM, Euler Taveira de Oliveira
> wrote:
>> BTW, are you going to submit another WIP patch for next commitfest?
>
> Well, Heikki was going to keep working on this and Hot Standby between
> CommitFests "until it gets
On Tue, 2009-11-03 at 15:01 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Tue, 2009-11-03 at 12:29 -0500, Robert Haas wrote:
> >> You're
> >> not going to take all those little dribs and drabs of responsibility
> >> and transfer them to one person, or even one group of people.
>
> > With re
On Nov 3, 2009, at 10:17 PM, Emmanuel Cecchet
wrote:
Hi all,
It looks like Postgres has a restriction in DISTINCT ON queries
where the DISTINCT ON expressions must match the left side of the
ORDER BY list. The issue is that if a DISTINCT ON ... has multiple
instances of a particular ex
On Wed, Nov 4, 2009 at 3:17 AM, Emmanuel Cecchet wrote:
> For example, this query returns an error (but I guess it shouldn't):
>
> 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
Hi,
On Tue, Nov 3, 2009 at 3:23 AM, Heikki Linnakangas
wrote:
> wrt. synchronous replication, if someone else has the cycles to look at
> it, that would be great. I got stuck on the postmaster-process or not
> question Fujii raised again now, not being able to decide.
What is your worry about th
Hi all,
It looks like Postgres has a restriction in DISTINCT ON queries where the
DISTINCT ON expressions must match the left side of the ORDER BY list. The
issue is that if a DISTINCT ON ... has multiple instances of a particular
expression, this check doesn't seem to fire correctly.
For exa
2009/11/3 Tom Lane :
> Jeff Davis writes:
>> I'm not excited about using NOT, because I think it has a hint of a
>> double-negative when combined with EXCLUSION.
>
> Well, the choice of EXCLUSION isn't set in stone either ...
>
Is this really a generalized uniqueness constraint, extended to
suppo
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
The other Greg wrote:
> Realistically we're going to EOL it as soon as the first major bug is
> found that *doesn't* back patch readily. There's relatively low cost
> to supp
Is a somewhat related question "how long are the various commercial
support organizations committed to supporting 7.4"?
I guess support companies might support their client's systems
for longer or shorter times than the community patches the old
versions. No doubt it's easier for them if the com
Simon Riggs writes:
> On Tue, 2009-11-03 at 12:29 -0500, Robert Haas wrote:
>> You're
>> not going to take all those little dribs and drabs of responsibility
>> and transfer them to one person, or even one group of people.
> With respect to all the people you just mentioned, I don't see any
> rea
On Tue, 2009-11-03 at 21:31 +, Dean Rasheed wrote:
> Is this really a generalized uniqueness constraint, extended to
> support operators other than = ?
That has been discussed in the past:
http://archives.postgresql.org/message-id/1253119552.24770.203.ca...@jdavis
http://archives.postgresql.o
On Tue, Nov 3, 2009 at 5:05 PM, Jeff Davis wrote:
> We already have some reasonable agreement around EXCLUSION ... CHECK
> WITH. We should stick with the current syntax unless there's a good
> consensus around some other specific proposal.
Yeah. I don't like the inflexibility of the current synt
Josh Berkus wrote:
...The main reason I'm in favor of this is that we have a lot of users
using 7.4 out of inertia, and they need a message that 7.4 is "not
supported" to get them to upgrade.
I'm not entirely sure that inertia is the culprit. From what I've seen,
since 7.4 is a good, stable rele
On Tue, Nov 3, 2009 at 7:24 PM, Greg Sabino Mullane wrote:
>> Realistically we're going to EOL it as soon as the first major bug is
>> found that *doesn't* back patch readily. There's relatively low cost
>> to supporting it up until that bug is found, and apparently it hasn't
>> been found it.
>
>
On Tue, Nov 3, 2009 at 2:24 PM, Greg Sabino Mullane wrote:
> That will get some, but not others. What really makes people upgrade
> their database is when their database driver stops working against it. :)
ROFL.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Tue, Nov 3, 2009 at 1:32 PM, Josh Berkus wrote:
> Also, as Greg points out, 7.4 is just waiting for some exploit which is
> horribly hard to backpatch for us to desupport it on short notice, and
> that is NOT a service to our users.
That is along the line of my concerns as well. Based on a qu
Simon,
> Why are we not even willing to ask
> whether someone is willing? It all seems very strange to me.
Mostly because, I think, nobody can picture how this would be structured
or where the people would come from. Surely a "7.4 maintainer" would do
only one platform? Or only source? Can w
On Tue, 2009-11-03 at 10:49 -0800, Josh Berkus wrote:
> > Why are we not even willing to ask
> > whether someone is willing? It all seems very strange to me.
>
> Mostly because, I think, nobody can picture how this would be structured
> or where the people would come from. Surely a "7.4 maintai
On Tue, Nov 03, 2009 at 10:32:17AM -0800, Josh Berkus wrote:
> So I'm going to make a case in favor of EOL'ing 7.4. In fact, I'd be in
> favor of doing so in, say, February after an announcement this month.
>
> The main reason I'm in favor of this is that we have a lot of users
> using 7.4 out of
On Nov 3, 2009, at 10:32 AM, Josh Berkus wrote:
So I'm going to make a case in favor of EOL'ing 7.4. In fact, I'd
be in
favor of doing so in, say, February after an announcement this month
+1
And, frankly, I think that we still need a published deprecation
policy -- or at least a set of
On Tue, 2009-11-03 at 10:04 -0800, Steve Crawford wrote:
> Users are, of course, free to use/self-support the software as they see
> fit. It's open-source, after all.
I've heard that a lot recently: "It's open source, after all".
Is this project not open source any more?
Surely this project sh
Many people still run [7.4], so why make them move?
Many people still run 7.3... We made them move..
A nitpick. Nobody "made" anyone move.
PHP 4 was EOL some time ago but is still in widespread use. We still see
occasional postings regarding 7.3 and sometimes even earlier.
The softwar
On Tue, 2009-11-03 at 12:29 -0500, Robert Haas wrote:
> You're
> not going to take all those little dribs and drabs of responsibility
> and transfer them to one person, or even one group of people.
With respect to all the people you just mentioned, I don't see any
reason why other people could not
All,
So I'm going to make a case in favor of EOL'ing 7.4. In fact, I'd be in
favor of doing so in, say, February after an announcement this month.
The main reason I'm in favor of this is that we have a lot of users
using 7.4 out of inertia, and they need a message that 7.4 is "not
supported" to
Hi,
On Wed, Nov 4, 2009 at 12:01 AM, Andrew Gierth
wrote:
> 2) you're starting up in a data dir that is a restore of a base backup,
> but no recovery.conf has been created
Is the scenario 2 (i.e., a normal crash recovery without recovery.conf)
supported in postgres? But, anyway, it's possible
On Tue, Nov 3, 2009 at 5:23 PM, Robert Haas wrote:
> Well, that would be overstating my position. We haven't stopped
> supporting it, but there's less and less stuff that applies that far
> back. I think it's better to draw a line in the sand and say "we're
> going to stop supporting this releas
On Tue, Nov 3, 2009 at 10:46 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Robert Haas wrote:
>>> Part of the reason I suggest this is because it seems that not much
>>> gets patched back that far any more.
>
>> Tom just backpatched something to 7.4 the other day.
>
> A quick look in the cvs hi
Heikki Linnakangas writes:
> ... But pointing to ESCAPE is just weird.
Maybe. The implementation's-eye view of this is that the construct is
data SIMILAR-operator (pattern ESCAPE-operator escape-char)
but I agree that isn't the way a user will think of it. I could see
making the locat
On Tue, 2009-11-03 at 16:37 +, Dave Page wrote:
> On Tue, Nov 3, 2009 at 4:29 PM, Simon Riggs wrote:
>
> > Unless there are unfixable data loss bugs in it, I say we keep it.
> >
> > Many people still run it, so why make them move?
>
> There are non-trivial amounts of effort required to produ
Jeff Davis writes:
> I'm not excited about using NOT, because I think it has a hint of a
> double-negative when combined with EXCLUSION.
Well, the choice of EXCLUSION isn't set in stone either ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Uh, why? It looks like it's complaining about the constant 123,
>> not about the operator.
> I wrote that before I saw your post, which left me ambivalent. My
> thinking was that it seems clearest to me when it points to the token
> at which thing
Tom Lane wrote:
> Heikki Linnakangas writes:
>> BTW, the corresponding error in the "SIMILAR TO ... ESCAPE ..." syntax is:
>
>> postgres=# SELECT 'aa' SIMILAR TO 123 ESCAPE 'f';
>> ERROR: function pg_catalog.similar_escape(integer, unknown) does not exist
>> LINE 1: SELECT 'aa' SIMILAR TO 123 ES
Simon Riggs writes:
> Personally, I would be more inclined to keep 7.4 as a supported version
> and remove support for 8.0, possibly 8.1 also.
That would be basically useless from a maintenance-effort perspective
--- if you don't work back through the branches in a methodical way when
back-patchi
Heikki Linnakangas writes:
> BTW, the corresponding error in the "SIMILAR TO ... ESCAPE ..." syntax is:
> postgres=# SELECT 'aa' SIMILAR TO 123 ESCAPE 'f';
> ERROR: function pg_catalog.similar_escape(integer, unknown) does not exist
> LINE 1: SELECT 'aa' SIMILAR TO 123 ESCAPE 'f';
>
On Mon, 2009-11-02 at 18:28 +, Simon Riggs wrote:
> > I like the "NOT" here because "CHECK NOT =" seems to convey pretty
> > clearly what it is you are checking for. Because NOT is reserved and
> > can't appear as a connective, I think that this approach might allow
> > a non-reserved leading
2009/11/3 Simon Riggs :
> On Tue, 2009-11-03 at 16:37 +, Dave Page wrote:
>> On Tue, Nov 3, 2009 at 4:29 PM, Simon Riggs wrote:
>>
>> > Unless there are unfixable data loss bugs in it, I say we keep it.
>> >
>> > Many people still run it, so why make them move?
>>
>> There are non-trivial amou
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Heikki Linnakangas wrote:
>>> LINE 1: SELECT 'aa' NOT SIMILAR TO 123;
>>>^
>
>>> LINE 1: SELECT 'aa' SIMILAR TO 123;
>>> ^
>
>>> I think the former error location is better.
>
>> So do I.
>
On Tue, 2009-11-03 at 16:37 +, Dave Page wrote:
> On Tue, Nov 3, 2009 at 4:29 PM, Simon Riggs wrote:
>
> > Unless there are unfixable data loss bugs in it, I say we keep it.
> >
> > Many people still run it, so why make them move?
>
> There are non-trivial amounts of effort required to produ
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Heikki Linnakangas wrote:
>>> LINE 1: SELECT 'aa' NOT SIMILAR TO 123;
>>>^
>
>>> LINE 1: SELECT 'aa' SIMILAR TO 123;
>>> ^
>
>>> I think the former error location is better.
>
>> So do I.
On Tue, Nov 3, 2009 at 4:29 PM, Simon Riggs wrote:
> Unless there are unfixable data loss bugs in it, I say we keep it.
>
> Many people still run it, so why make them move?
There are non-trivial amounts of effort required to produce and test
packages for each branch we maintain. That affects all
2009/11/3 Simon Riggs :
> On Tue, 2009-11-03 at 13:01 -0300, Alvaro Herrera wrote:
>> Tom Lane escribió:
>>
>> > A quick look in the cvs history shows 5 commits to 7.4 since the last
>> > set of releases, 6 commits to 8.0, 8 to 8.1, 13 to 8.2, 18 to 8.3.
>> > A couple of these patches were Windows-
On Tue, 2009-11-03 at 13:01 -0300, Alvaro Herrera wrote:
> Tom Lane escribió:
>
> > A quick look in the cvs history shows 5 commits to 7.4 since the last
> > set of releases, 6 commits to 8.0, 8 to 8.1, 13 to 8.2, 18 to 8.3.
> > A couple of these patches were Windows-specific and were made only ba
Magnus Hagander wrote:
2009/11/3 Andrew Dunstan :
Robert Haas wrote:
We had a discussion back in July about our maintenance policy and the
upshot of that discussion was that there were relatively few
objections to dropping support for 7.4 - I believe Andrew Dunstan was
the only one who spoke a
"Kevin Grittner" writes:
> Heikki Linnakangas wrote:
>> LINE 1: SELECT 'aa' NOT SIMILAR TO 123;
>>^
>> LINE 1: SELECT 'aa' SIMILAR TO 123;
>> ^
>> I think the former error location is better.
> So do I.
Uh, why? It looks like it's co
Tom Lane escribió:
> A quick look in the cvs history shows 5 commits to 7.4 since the last
> set of releases, 6 commits to 8.0, 8 to 8.1, 13 to 8.2, 18 to 8.3.
> A couple of these patches were Windows-specific and were made only back
> to 8.2 because we desupported Windows in older branches awhile
[ after further thought... ]
Andrew Gierth writes:
> How do you distinguish between these two scenarios:
> 1) you're starting up in a data dir where you crashed in the middle of
>a backup
> 2) you're starting up in a data dir that is a restore of a base backup,
>but no recovery.conf has
Heikki Linnakangas wrote:
> LINE 1: SELECT 'aa' NOT SIMILAR TO 123;
>^
> LINE 1: SELECT 'aa' SIMILAR TO 123;
> ^
> I think the former error location is better.
So do I.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
Andrew Dunstan writes:
> Robert Haas wrote:
>> Part of the reason I suggest this is because it seems that not much
>> gets patched back that far any more.
> Tom just backpatched something to 7.4 the other day.
A quick look in the cvs history shows 5 commits to 7.4 since the last
set of releases,
2009/11/3 Andrew Dunstan :
>
>
> Robert Haas wrote:
>>
>> We had a discussion back in July about our maintenance policy and the
>> upshot of that discussion was that there were relatively few
>> objections to dropping support for 7.4 - I believe Andrew Dunstan was
>> the only one who spoke against
Tom Lane wrote:
> Peter Eisentraut writes:
>> Is anyone planning to do further work on this? This appears to be
>> blocking the client_encoding=auto feature.
>
> Huh? Why would there be any linkage? This is just offering an
> alternative way to set connection options, it has nothing to do
> wi
> "Albe" == "Albe Laurenz" writes:
Albe> Removing postmaster.pid can lead to a corrupt database.
Albe> Removing backup_label means that one of your backups will go
Albe> wrong, and a subsequent pg_stop_backup() will throw an error.
Albe> If you have a cluster failover during an online ba
Robert Haas wrote:
We had a discussion back in July about our maintenance policy and the
upshot of that discussion was that there were relatively few
objections to dropping support for 7.4 - I believe Andrew Dunstan was
the only one who spoke against it, and it wasn't clear how strenuous
his ob
On Tue, 2009-11-03 at 09:32 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > Is anyone planning to do further work on this? This appears to be
> > blocking the client_encoding=auto feature.
>
> Huh? Why would there be any linkage? This is just offering an
> alternative way to set connecti
Heikki Linnakangas writes:
> Here's an example that exercises those paths:
> postgres=# SELECT 'aa' NOT SIMILAR TO 123;
> ERROR: function pg_catalog.similar_escape(integer, unknown) does not exist
> LINE 1: SELECT 'aa' NOT SIMILAR TO 123;
>^
> HINT: No functi
Peter Eisentraut writes:
> Is anyone planning to do further work on this? This appears to be
> blocking the client_encoding=auto feature.
Huh? Why would there be any linkage? This is just offering an
alternative way to set connection options, it has nothing to do
with what the set of options i
We had a discussion back in July about our maintenance policy and the
upshot of that discussion was that there were relatively few
objections to dropping support for 7.4 - I believe Andrew Dunstan was
the only one who spoke against it, and it wasn't clear how strenuous
his objections were - but the
On Tue, Nov 3, 2009 at 7:51 AM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Tue, Nov 3, 2009 at 6:25 AM, Alvaro Herrera
>> wrote:
>> >> > If this is the case, then I think we could just decide that their name
>> >> > is reloptions due to hysterical reasons and be done with it.
>> >>
>> >>
On Tue, Nov 3, 2009 at 7:44 AM, Dimitri Fontaine wrote:
> Robert Haas writes:
>>> Le 1 nov. 2009 à 13:43, Greg Stark a écrit :
We could have a column for all booleans, a column for all integers,
etc. but that's not really any more normalized than having a single
column for al
Robert Haas escribió:
> On Tue, Nov 3, 2009 at 6:25 AM, Alvaro Herrera
> wrote:
> >> > If this is the case, then I think we could just decide that their name
> >> > is reloptions due to hysterical reasons and be done with it.
> >>
> >> Yeah. It's particularly unfortunate that we call them "relopt
Robert Haas writes:
>> Le 1 nov. 2009 à 13:43, Greg Stark a écrit :
>>>
>>> We could have a column for all booleans, a column for all integers,
>>> etc. but that's not really any more normalized than having a single
>>> column for all the types with a rule for how to marshal each value
>>> type.
On Tue, Nov 3, 2009 at 6:25 AM, Alvaro Herrera
wrote:
>> > If this is the case, then I think we could just decide that their name
>> > is reloptions due to hysterical reasons and be done with it.
>>
>> Yeah. It's particularly unfortunate that we call them "reloptions" in
>> the code but "storage
On Sun, 2009-09-27 at 21:49 -0400, Robert Haas wrote:
> On Wed, Sep 23, 2009 at 3:26 PM, Tom Lane wrote:
> > Jaime Casanova writes:
> >> i extracted the functions to connect that Heikki put on psql in his
> >> patch for determining client_encoding from client locale and put it in
> >> libpq so i
Robert Haas escribió:
> On Mon, Nov 2, 2009 at 12:40 PM, Alvaro Herrera
> wrote:
> > Robert Haas escribió:
> >
> >> I don't see anything in this code that is very rel-specific, so I
> >> think it would be possible to implement spcoptions by just defining
> >> RELOPT_KIND_TABLESPACE and ignoring th
Tom Lane wrote:
> > I wonder why backup_label isn't automatically removed
> > in normal crash recovery case.
>
> Removing it automatically could be catastrophic if done
> incorrectly, no?
>
> It would be no less catastrophic if done incorrectly from outside the
> postmaster; see for example the
On Sat, 2009-10-31 at 14:24 +0200, Peter Eisentraut wrote:
> I have discovered an obscure segfault condition in PL/Python. In
> PLy_output(), when the elog() call in the TRY branch throws an exception
> (this can happen when a statement timeout kicks in, for example), the
> PyErr_SetString() call
70 matches
Mail list logo
