Tom Lane wrote:
> Itagaki Takahiro writes:
> > Should we have "INHERITS ( parent INCLUDING xxx )" syntax ?
>
> No. That would imply that the user has some control over what is
> inherited and what isn't, which would be a complete mess.
Hmmm, but users can already control using LIKE INCLUDING
shrish purohit wrote:
> Updated Kedar's patch sending on behalf of Kedar.
> There are not toomany modifications. It includes improvements for validating
> multi-column partitioned tables.
Thanks, but I'd like to keep the first patch as possible as simple.
I'll refer your work in the *next* step
On Sun, 2009-11-01 at 15:42 -0800, Jeff Davis wrote:
> Most of the time, there will be two columns like:
> EXCLUSION(room_number CHECK WITH =, during CHECK WITH &&)
Now that's a great example.
Looks like the classic "don't allow the same room to be booked more than
once at the same time".
It
Hi,
Is there a reason not to remove backup_label automatically when crash recovery
is run?
ereport in StartXLOG() says the folloing hint message, but I can't see other
cases we have to take care;
ereport(PANIC,
(errmsg("could not locate required checkpoint record"),
Hi,
When a crash occurs before calling pg_stop_backup(),
the subsequent crash recovery causes the FATAL error
and outputs the following HINT message.
If you are not restoring from a backup, try removing the file
\"%s/backup_label\"."
I wonder why backup_label isn't automatically removed
in n
Hi,
>> Is this the same as / similar to Oracle's syntax?
>
> Yes.
>
>> IIRC Nikhil's patch was Oracle's syntax
>
> No. See:
> http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/statements_7002.htm#i2125922
>
Any decent prevalent partitioning syntax should be ok IMHO. IIRC,
MySQL parit
On Sun, 2009-11-01 at 23:09 -0500, Robert Haas wrote:
> Following that thought, in this particular case it seems like you could do:
>
> EXCLUSION (room CHECK WITH =,
> attendee CHECK WITH =,
> foobar CHECK WITH =,
> during CHECK WITH &&)
> and then
On Sun, 2009-11-01 at 22:49 -0500, Tom Lane wrote:
> you should have no hard-wired upper bound on
> how many of them you allow.
You're right. I saw something that looked easy to implement, but in
practice it wouldn't be very useful.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing
On Sun, Nov 1, 2009 at 10:49 PM, Tom Lane wrote:
> Jeff Davis writes:
>> It could go something like this (syntax still open for discussion, for
>> illustration only):
>
>> EXCLUSION (room CHECK WITH =,
>> attendee CHECK WITH =,
>> during CHECK WITH &&)
>> CAR
Jeff Davis writes:
> It could go something like this (syntax still open for discussion, for
> illustration only):
> EXCLUSION (room CHECK WITH =,
> attendee CHECK WITH =,
> during CHECK WITH &&)
> CARDINALITY 30
There's an old design principle that says "the
Devrim GNDZ wrote:
> Is this the same as / similar to Oracle's syntax?
Yes.
> IIRC Nikhil's patch was Oracle's syntax
No. See:
http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/statements_7002.htm#i2125922
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
--
Sen
I have completed the open issues (that I'm aware of) for operator
exclusion constraints:
http://archives.postgresql.org/message-id/1257101600.27737.159.ca...@jdavis
I'd now like to propose an extension to that feature: cardinality
limits.
It could go something like this (syntax still open for di
On Sun, 2009-11-01 at 22:42 +, Simon Riggs wrote:
> After reading the docs in the patch I don't believe you're going to all
> this trouble to ensure two circles don't overlap. Can you give some
> better examples of what you're trying to achieve and why anyone else
> would care? (I'm busy, so ar
Simon Riggs writes:
> The syntax be easier to read if it was stated as a comparison
> e.g. in the circle example
> CHECK ( NOT (NEW.c && c)) USING GIST
I don't think this is a good idea at all. NEW is a nonstandard
Postgres-ism, and introducing it into this syntax doesn't seem very
future-proo
> After reading the docs in the patch I don't believe you're going to all
> this trouble to ensure two circles don't overlap. Can you give some
> better examples of what you're trying to achieve and why anyone else
> would care? (I'm busy, so are others).
>
Non overlapping time intervals is one us
On Sun, 2009-11-01 at 10:53 -0800, Jeff Davis wrote:
> New patch attached.
After reading the docs in the patch I don't believe you're going to all
this trouble to ensure two circles don't overlap. Can you give some
better examples of what you're trying to achieve and why anyone else
would care? (
2009/11/2 Alvaro Herrera :
> Peter Eisentraut wrote:
>> As a compromise, we could keep the combined "Attributes" column but
>> replace the line breaks by commas. This would at least get rid of the
>> confusing and ugly line breaks in the common cases.
>
> That works for me.
Mmm, perhaps we were a
Peter Eisentraut wrote:
> As a compromise, we could keep the combined "Attributes" column but
> replace the line breaks by commas. This would at least get rid of the
> confusing and ugly line breaks in the common cases.
That works for me.
--
Alvaro Herrerahttp:/
On Nov 1, 2009, at 10:12 AM, Tom Lane wrote:
Robert Haas writes:
On Sat, Oct 31, 2009 at 5:00 PM, Marko Tiikkaja
wrote:
What I've had in mind is pipelining the execution only when it
doesn't
have *any* impact on the outcome. This would mean only allowing
it when
the top-level statement
Marko Tiikkaja writes:
> I've previously thought about making the CTE aware of the LIMIT,
> similarly to a top-N sort, but I don't think it's worth it.
That approach doesn't lead to a solution because then you could *never*
optimize it. The protocol-level limit option is always present.
It's co
Tom Lane wrote:
However, this still doesn't address the problem of what happens when the
top-level select fails to read all of the CTE output (because it has a
LIMIT, or the client doesn't read all the output of a portal, etc etc).
Partially executing an update in such cases is no good.
I've pr
Hi,
While playing around/evaluating tsearch I notices that to_tsvector is
obscenely slow for some files. After some profiling I found that this is due
using a seperate TSParser in p_ishost/p_isURLPath in wparser_def.c.
If a multibyte encoding is in use TParserInit copies the whole remaining inpu
Robert Haas wrote:
You'd also have to disallow the case when there are any triggers on
the INSERT, or where there are any triggers on anything else (because
they might access the target table of the INSERT). This will end up
being so restricted as to be useless.
I might be wrong here, but I do
Robert Haas writes:
> On Sat, Oct 31, 2009 at 5:00 PM, Marko Tiikkaja
> wrote:
>> What I've had in mind is pipelining the execution only when it doesn't
>> have *any* impact on the outcome. This would mean only allowing it when
>> the top-level statement is either a SELECT or an INSERT. Also, U
On Nov 1, 2009, at 7:43 AM, Greg Stark wrote:
On Sat, Oct 31, 2009 at 6:04 PM, Robert Haas
wrote:
Looking at this a little more, it seems that part of the motivation
for the existing design is that user-created AMs might require
arbitrary options, which therefore can't be wired into the syst
On Sat, Oct 31, 2009 at 6:04 PM, Robert Haas wrote:
> Looking at this a little more, it seems that part of the motivation
> for the existing design is that user-created AMs might require
> arbitrary options, which therefore can't be wired into the system
> catalogs. There's no equivalent for tabl
26 matches
Mail list logo
