On Fri, Sep 4, 2015 at 09:40:10AM +0900, Michael Paquier wrote:
> Robert Haas wrote:
> > On Wed, Aug 26, 2015 at 3:31 PM, Alvaro Herrera
> > wrote:
> > > Fabrízio de Royes Mello wrote:
> > >
> > >> Why this patch was reverted one day after applied [1]? I didn't see
> a
On Fri, Sep 4, 2015 at 3:52 AM, Alvaro Herrera
wrote:
> Robert Haas wrote:
> > On Wed, Aug 26, 2015 at 3:31 PM, Alvaro Herrera
> > wrote:
> > > Fabrízio de Royes Mello wrote:
> > >
> > >> Why this patch was reverted one day after applied [1]? I didn't see
> any
> > >> discussion around it.
> > >
Robert Haas wrote:
> On Wed, Aug 26, 2015 at 3:31 PM, Alvaro Herrera
> wrote:
> > Fabrízio de Royes Mello wrote:
> >
> >> Why this patch was reverted one day after applied [1]? I didn't see any
> >> discussion around it.
> >
> > Contributors whose patches are getting committed should really subscr
On Wed, Aug 26, 2015 at 3:31 PM, Alvaro Herrera
wrote:
> Fabrízio de Royes Mello wrote:
>
>> Why this patch was reverted one day after applied [1]? I didn't see any
>> discussion around it.
>
> Contributors whose patches are getting committed should really subscribe
> to pgsql-committers.
I would
On Wed, Aug 26, 2015 at 4:31 PM, Alvaro Herrera
wrote:
>
> Fabrízio de Royes Mello wrote:
>
> > Why this patch was reverted one day after applied [1]? I didn't see any
> > discussion around it.
>
> Contributors whose patches are getting committed should really subscribe
> to pgsql-committers.
>
O
On Wed, Aug 26, 2015 at 4:30 PM, Andres Freund wrote:
>
> On 2015-08-26 16:24:31 -0300, Fabrízio de Royes Mello wrote:
> > Why this patch was reverted one day after applied [1]? I didn't see any
> > discussion around it.
>
> http://www.postgresql.org/message-id/23918.1409010...@sss.pgh.pa.us
Tha
Fabrízio de Royes Mello wrote:
> Why this patch was reverted one day after applied [1]? I didn't see any
> discussion around it.
Contributors whose patches are getting committed should really subscribe
to pgsql-committers.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL
On 2015-08-26 16:24:31 -0300, Fabrízio de Royes Mello wrote:
> Why this patch was reverted one day after applied [1]? I didn't see any
> discussion around it.
http://www.postgresql.org/message-id/23918.1409010...@sss.pgh.pa.us
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On 26 August 2015 at 20:24, Fabrízio de Royes Mello wrote:
>
> On Mon, Aug 25, 2014 at 6:07 PM, Bruce Momjian wrote:
> >
> > On Fri, Aug 22, 2014 at 10:04:50PM -0400, Bruce Momjian wrote:
> > > On Fri, Aug 22, 2014 at 03:12:47PM -0400, Robert Haas wrote:
> > > > On Fri, Aug 22, 2014 at 2:33 PM,
On Mon, Aug 25, 2014 at 6:07 PM, Bruce Momjian wrote:
>
> On Fri, Aug 22, 2014 at 10:04:50PM -0400, Bruce Momjian wrote:
> > On Fri, Aug 22, 2014 at 03:12:47PM -0400, Robert Haas wrote:
> > > On Fri, Aug 22, 2014 at 2:33 PM, Bruce Momjian
wrote:
> > > >> Yes, you remember well. I will have to fi
On Fri, Aug 22, 2014 at 10:04:50PM -0400, Bruce Momjian wrote:
> On Fri, Aug 22, 2014 at 03:12:47PM -0400, Robert Haas wrote:
> > On Fri, Aug 22, 2014 at 2:33 PM, Bruce Momjian wrote:
> > >> Yes, you remember well. I will have to find a different way for
> > >> pg_upgrade to call a no-op ALTER TA
On Fri, Aug 22, 2014 at 03:12:47PM -0400, Robert Haas wrote:
> On Fri, Aug 22, 2014 at 2:33 PM, Bruce Momjian wrote:
> >> Yes, you remember well. I will have to find a different way for
> >> pg_upgrade to call a no-op ALTER TABLE, which is fine.
> >
> > Looking at the ALTER TABLE options, I am go
On Fri, Aug 22, 2014 at 2:33 PM, Bruce Momjian wrote:
>> Yes, you remember well. I will have to find a different way for
>> pg_upgrade to call a no-op ALTER TABLE, which is fine.
>
> Looking at the ALTER TABLE options, I am going to put this check in a
> !IsBinaryUpgrade block so pg_upgrade can s
On August 22, 2014 8:33:57 PM CEST, Bruce Momjian wrote:
>On Fri, Aug 22, 2014 at 12:53:30PM -0400, Bruce Momjian wrote:
>> On Fri, Aug 22, 2014 at 10:27:02AM -0400, Robert Haas wrote:
>> > On Thu, Aug 21, 2014 at 7:17 PM, Bruce Momjian
>wrote:
>> > > On Tue, Mar 18, 2014 at 09:11:46AM -0400, Rob
On Fri, Aug 22, 2014 at 12:53:30PM -0400, Bruce Momjian wrote:
> On Fri, Aug 22, 2014 at 10:27:02AM -0400, Robert Haas wrote:
> > On Thu, Aug 21, 2014 at 7:17 PM, Bruce Momjian wrote:
> > > On Tue, Mar 18, 2014 at 09:11:46AM -0400, Robert Haas wrote:
> > >> On Mon, Mar 17, 2014 at 10:27 PM, Michae
On Fri, Aug 22, 2014 at 10:27:02AM -0400, Robert Haas wrote:
> On Thu, Aug 21, 2014 at 7:17 PM, Bruce Momjian wrote:
> > On Tue, Mar 18, 2014 at 09:11:46AM -0400, Robert Haas wrote:
> >> On Mon, Mar 17, 2014 at 10:27 PM, Michael Paquier
> >> wrote:
> >> > On Tue, Mar 18, 2014 at 10:24 AM, Fabrízi
On Thu, Aug 21, 2014 at 7:17 PM, Bruce Momjian wrote:
> On Tue, Mar 18, 2014 at 09:11:46AM -0400, Robert Haas wrote:
>> On Mon, Mar 17, 2014 at 10:27 PM, Michael Paquier
>> wrote:
>> > On Tue, Mar 18, 2014 at 10:24 AM, Fabrízio de Royes Mello
>> > wrote:
>> >>
>> >> On Thu, Mar 13, 2014 at 10:22
On Tue, Mar 18, 2014 at 09:11:46AM -0400, Robert Haas wrote:
> On Mon, Mar 17, 2014 at 10:27 PM, Michael Paquier
> wrote:
> > On Tue, Mar 18, 2014 at 10:24 AM, Fabrízio de Royes Mello
> > wrote:
> >>
> >> On Thu, Mar 13, 2014 at 10:22 AM, Robert Haas
> >> wrote:
> >>> Well, it's fairly harmless
On Mon, Mar 17, 2014 at 10:27 PM, Michael Paquier
wrote:
> On Tue, Mar 18, 2014 at 10:24 AM, Fabrízio de Royes Mello
> wrote:
>>
>> On Thu, Mar 13, 2014 at 10:22 AM, Robert Haas wrote:
>>> Well, it's fairly harmless, but it might not be a bad idea to tighten that
>>> up.
>> The attached patch ti
On Tue, Mar 18, 2014 at 10:24 AM, Fabrízio de Royes Mello
wrote:
>
> On Thu, Mar 13, 2014 at 10:22 AM, Robert Haas wrote:
>> Well, it's fairly harmless, but it might not be a bad idea to tighten that
>> up.
> The attached patch tighten that up.
Hm... It might be interesting to include it in 9.4 I
On Thu, Mar 13, 2014 at 10:22 AM, Robert Haas wrote:
>
> On Wed, Mar 12, 2014 at 11:11 PM, Fabrízio de Royes Mello
> wrote:
> > Hi all,
> >
> > Shouldn't the "ALTER" statements below raise an exception?
> >
> > fabrizio=# CREATE TABLE foo(bar SERIAL PRIMARY KEY);
> > CREATE TABLE
> >
> > fabrizio
fabriziomello wrote
> On Thu, Mar 13, 2014 at 10:34 AM, Euler Taveira <
> euler@.com
> >
> wrote:
>>
>> On 13-03-2014 00:11, Fabrízio de Royes Mello wrote:
>> > Shouldn't the "ALTER" statements below raise an exception?
>> >
>> For consistency, yes. Who cares? I mean, there is no harm in resettin
On Thu, Mar 13, 2014 at 10:34 AM, Euler Taveira
wrote:
>
> On 13-03-2014 00:11, Fabrízio de Royes Mello wrote:
> > Shouldn't the "ALTER" statements below raise an exception?
> >
> For consistency, yes. Who cares? I mean, there is no harm in resetting
> an unrecognized parameter. Have in mind that
On 13-03-2014 00:11, Fabrízio de Royes Mello wrote:
> Shouldn't the "ALTER" statements below raise an exception?
>
For consistency, yes. Who cares? I mean, there is no harm in resetting
an unrecognized parameter. Have in mind that tighten it up could break
scripts. In general, I'm in favor of vali
On Wed, Mar 12, 2014 at 11:11 PM, Fabrízio de Royes Mello
wrote:
> Hi all,
>
> Shouldn't the "ALTER" statements below raise an exception?
>
> fabrizio=# CREATE TABLE foo(bar SERIAL PRIMARY KEY);
> CREATE TABLE
>
> fabrizio=# SELECT relname, reloptions FROM pg_class WHERE relname ~ '^foo';
>rel
Hi all,
Shouldn't the "ALTER" statements below raise an exception?
fabrizio=# CREATE TABLE foo(bar SERIAL PRIMARY KEY);
CREATE TABLE
fabrizio=# SELECT relname, reloptions FROM pg_class WHERE relname ~ '^foo';
relname | reloptions
-+
foo |
foo_bar_seq |
foo
"David E. Wheeler" writes:
> On Jan 17, 2010, at 3:47 PM, Tom Lane wrote:
>>> create type y as (c char, n int);
>>> select ('a', NULL)::y = ('a', NULL)::y; -- TRUE
>>> select ('a', NULL) = ('a', NULL); -- NULL
>> The latter gets simplified to ('a' = 'a') AND (NULL = NULL).
>> The former doesn't
On Jan 17, 2010, at 3:47 PM, Tom Lane wrote:
>> create type y as (c char, n int);
>> select ('a', NULL)::y = ('a', NULL)::y; -- TRUE
>> select ('a', NULL) = ('a', NULL); -- NULL
>
>> I would expect those to evaluate to the same thing.
>
> The latter gets simplified to ('a' = 'a') AND (NULL =
On Sun, 2010-01-17 at 18:47 -0500, Tom Lane wrote:
> The former might be closer to the spec's expectations but I'm not
> totally sure about it.
I suppose that people using NULLs should expect the unexpected ;)
I don't have strong feelings about it, I just wanted to raise the issue.
Regards,
Jeff Davis writes:
> create type y as (c char, n int);
> select ('a', NULL)::y = ('a', NULL)::y; -- TRUE
> select ('a', NULL) = ('a', NULL); -- NULL
> I would expect those to evaluate to the same thing.
The latter gets simplified to ('a' = 'a') AND (NULL = NULL).
The former doesn't --- it
create type y as (c char, n int);
select ('a', NULL)::y = ('a', NULL)::y; -- TRUE
select ('a', NULL) = ('a', NULL); -- NULL
I would expect those to evaluate to the same thing.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
"Matthew T. O'Connor" writes:
> Now, I know I can specify a constraint name inside the alter command,
> but I still expected this to work.
It does, in 8.0.
regression=# create table foo (id1 int, id2 int, id3 int);
CREATE TABLE
regression=# ALTER TABLE foo ADD unique (id1,id2);
NOTICE: ALTER T
On Tue, Jan 25, 2005 at 12:43:16PM -0500, Matthew T. O'Connor wrote:
> foo=# ALTER TABLE foo ADD unique (id1,id3);
> NOTICE: ALTER TABLE / ADD UNIQUE will create implicit index
> "foo_id1_key" for table "foo"
> ERROR: relation "foo_id1_key" already exists
8.0.0 handles this situation better:
I think this may have been discussed before but I found this a bit
surprising:
foo=# SELECT version();
version
-
PostgreS
"Roberto Abalde" <[EMAIL PROTECTED]> writes:
> I've found that some two functions in /src/backend/optimizer/plan/planner.c
> have side effects.
No kidding ;-). The planner is full of side-effects on data structures.
Both of the changes you mention are intentional.
regard
Hi people,
I've found that some two functions in /src/backend/optimizer/plan/planner.c
have side effects.
First, I've added two pprints before and after line 89-90 like this.
pprint(parse->rtable);
/* primary planning entry point (may recurse for subqueries) */
result_plan = subquery_planner
Dear all,
I've migrated from RedHat6.2/PHP3.0/PostgreSQL6.5 to
Mandrake/PHP4.0/Postgres7.0.2 successfully as far as
pg_dump database_name is concerned.
I am still running BOTH versions on two computers.
PostgreSQL6.5 does not produce any error using math function "integer
(float_expression)"
(
37 matches
Mail list logo