2016-07-31 17:53 GMT+02:00 Tom Lane :
> Pavel Stehule writes:
> > The SQL/XML syntax is:
>
> > XMLTABLE (
> > xmlquery
> > PASSING xmldocument
> > [COLUMNS columns_list] )
>
> > columns_list := column_list ',' colname
>
> > colname := colname datatype [DEFAULT value] [PATH text]
>
> > The D
Pavel Stehule writes:
> The SQL/XML syntax is:
> XMLTABLE (
> xmlquery
> PASSING xmldocument
> [COLUMNS columns_list] )
> columns_list := column_list ',' colname
> colname := colname datatype [DEFAULT value] [PATH text]
> The DEFAULT clause is before PATH clause.
> A Oracle db uses litt
Hi
I am working on xmltable function. This function is used for simple data
extraction from XML documents. In this moment I am working on prototype's
parser.
The SQL/XML syntax is:
XMLTABLE (
xmlquery
PASSING xmldocument
[COLUMNS columns_list] )
columns_list := column_list ',' colname
co
On Fri, Apr 1, 2016 at 3:22 PM, Jim Nasby wrote:
> On 4/1/16 1:08 PM, Tom Lane wrote:
>
>> Jim Nasby writes:
>>
>>> Rather than this, I think an exclusive-or operator would be a lot more
>>> useful. The only difficulty I run into with CHECK constaints is when I
>>> want to ensure that only ONE c
On 4/1/16 1:08 PM, Tom Lane wrote:
Jim Nasby writes:
Rather than this, I think an exclusive-or operator would be a lot more
useful. The only difficulty I run into with CHECK constaints is when I
want to ensure that only ONE condition is true.
"bool != bool" works as XOR. If you need "exactly
Jim Nasby writes:
> Rather than this, I think an exclusive-or operator would be a lot more
> useful. The only difficulty I run into with CHECK constaints is when I
> want to ensure that only ONE condition is true.
"bool != bool" works as XOR. If you need "exactly one of N" you could
do somethi
2016-04-01 18:57 GMT+02:00 David G. Johnston :
> On Thu, Mar 31, 2016 at 10:19 AM, Alexander Ostrow wrote:
>
>> Hello,
>>
>> I thought it would be cool to have conditional check syntax, which gets
>> converted to simple check constraint syntax.
>>
>> Here’s a gist:
>>
>> https://gist.github.com/a
On 3/31/16 12:19 PM, Alexander Ostrow wrote:
Hello,
I thought it would be cool to have conditional check syntax, which gets
converted to simple check constraint syntax.
Here’s a gist:
https://gist.github.com/aj0strow/5a07f2ddcad324c4dac2c4095c821999
It’s just sugar, but i think it would make
On Thu, Mar 31, 2016 at 10:19 AM, Alexander Ostrow wrote:
> Hello,
>
> I thought it would be cool to have conditional check syntax, which gets
> converted to simple check constraint syntax.
>
> Here’s a gist:
>
> https://gist.github.com/aj0strow/5a07f2ddcad324c4dac2c4095c821999
>
> It’s just suga
Hello,
I thought it would be cool to have conditional check syntax, which gets
converted to simple check constraint syntax.
Here’s a gist:
https://gist.github.com/aj0strow/5a07f2ddcad324c4dac2c4095c821999
It’s just sugar, but i think it would make check constraints easier to read,
and easier
On 1/13/14, 5:05 PM, Peter Geoghegan wrote:
On Mon, Jan 13, 2014 at 2:20 PM, Jim Nasby wrote:
Well, a common case for INSERT RETURNING is to get your set of surrogate
keys back; so I think users would want the ability to RETURN what finally
made it into the table.
Your update can also have a
On Mon, Jan 13, 2014 at 2:20 PM, Jim Nasby wrote:
> Well, a common case for INSERT RETURNING is to get your set of surrogate
> keys back; so I think users would want the ability to RETURN what finally
> made it into the table.
Your update can also have a RETURNING clause. I'm not necessarily that
On 1/12/14, 9:35 PM, Andreas Karlsson wrote:
On 01/12/2014 11:20 PM, Peter Geoghegan wrote:
On Sun, Jan 12, 2014 at 8:12 AM, Andreas Karlsson wrote:
On 01/11/2014 11:42 PM, Peter Geoghegan wrote:
I recently suggested that rather than RETURNING REJECTS, we could have
a REJECTING clause, which
On 01/12/2014 11:20 PM, Peter Geoghegan wrote:
On Sun, Jan 12, 2014 at 8:12 AM, Andreas Karlsson wrote:
On 01/11/2014 11:42 PM, Peter Geoghegan wrote:
I recently suggested that rather than RETURNING REJECTS, we could have
a REJECTING clause, which would see a DML statement project strictly
the
On Sun, Jan 12, 2014 at 8:12 AM, Andreas Karlsson wrote:
> On 01/11/2014 11:42 PM, Peter Geoghegan wrote:
>> I recently suggested that rather than RETURNING REJECTS, we could have
>> a REJECTING clause, which would see a DML statement project strictly
>> the complement of what RETURNING projects i
On 01/11/2014 11:42 PM, Peter Geoghegan wrote:
I recently suggested that rather than RETURNING REJECTS, we could have
a REJECTING clause, which would see a DML statement project strictly
the complement of what RETURNING projects in the same context. So
perhaps you could also see what RETURNING wo
On 01/12/2014 06:42 AM, Peter Geoghegan wrote:
> Someone suggested to me that I solicit opinion on the chosen syntax of
> INSERT...ON DUPLICATE KEY LOCK FOR UPDATE on a separate thread. I'll
> do that here, while also giving a formal user-level definition of the
> feature. I'd like to solicit feedb
Someone suggested to me that I solicit opinion on the chosen syntax of
INSERT...ON DUPLICATE KEY LOCK FOR UPDATE on a separate thread. I'll
do that here, while also giving a formal user-level definition of the
feature. I'd like to solicit feedback from a wider set of people than
those participating
Heikki Linnakangas writes:
> Accepting the keyword in such a context seems much harder to me than
> providing a hint. To accept the keyword, you'd need a lot of changes to
> the grammar, but for the hint, you just need some extra code in
> yyerror(). Mind you, if it's a hint, it doesn't need to
On 16.03.2012 14:50, Dimitri Fontaine wrote:
Peter Eisentraut writes:
Is there a reason for us not to add an HINT: "user" is a reserved
keyword or something like that, other than nobody having been interested
in doing the work?
If that were easily possible, we could just recognize 'user' as a
Peter Eisentraut writes:
>> Is there a reason for us not to add an HINT: "user" is a reserved
>> keyword or something like that, other than nobody having been interested
>> in doing the work?
>
> If that were easily possible, we could just recognize 'user' as an
> identifier in this context and av
On ons, 2012-03-14 at 14:58 +0100, Dimitri Fontaine wrote:
> A colleague came to me to express his surprise about this quite simple
> use case:
>
> =# alter table toto add column user text;
> ERROR: syntax error at or near "user"
> LINE 1: alter table toto add column user text;
>
> Is ther
2012/3/14 Pavel Stehule :
> 2012/3/14 Dimitri Fontaine :
>> Hi,
>>
>> A colleague came to me to express his surprise about this quite simple
>> use case:
>>
>> =# alter table toto add column user text;
>> ERROR: syntax error at or near "user"
>> LINE 1: alter table toto add column user text;
>>
On 14-03-2012 10:58, Dimitri Fontaine wrote:
> Is there a reason for us not to add an HINT: "user" is a reserved
> keyword or something like that, other than nobody having been interested
> in doing the work?
>
AFAIK, there is no such warning message in the code. If you're volunteering to
do it, p
2012/3/14 Dimitri Fontaine :
> Hi,
>
> A colleague came to me to express his surprise about this quite simple
> use case:
>
> =# alter table toto add column user text;
> ERROR: syntax error at or near "user"
> LINE 1: alter table toto add column user text;
>
> Is there a reason for us not to ad
Hi,
A colleague came to me to express his surprise about this quite simple
use case:
=# alter table toto add column user text;
ERROR: syntax error at or near "user"
LINE 1: alter table toto add column user text;
Is there a reason for us not to add an HINT: "user" is a reserved
keyword or
Martijn van Oosterhout writes:
> That said, I still don't see how you can enforce a unique index over
> multiple segments over something other than the partition key while
> still allowing quick dropping of segments. If you can fix that you can
> make it work for the current inheritence-style par
On Mon, Nov 14, 2011 at 10:33:36AM +0100, Dimitri Fontaine wrote:
> Martijn van Oosterhout writes:
> > While I agree that explicit partitioning is somewhat of a hack, it's a
> > really useful hack. But for me the most important use of partitioning
> > is "dropping a billion rows efficiently and g
Martijn van Oosterhout writes:
> While I agree that explicit partitioning is somewhat of a hack, it's a
> really useful hack. But for me the most important use of partitioning
> is "dropping a billion rows efficiently and getting the disk space
> back". And the biggest problem is always that dro
Tom Lane writes:
> to match the desired granularity of data removal. I don't really see
> any way that the database can be expected to know what that is, unless
> it's told in advance. So AFAICS you really have to have a declarative
> way of telling it how to do the partitioning --- it's not goi
Martijn van Oosterhout writes:
> While I agree that explicit partitioning is somewhat of a hack, it's a
> really useful hack. But for me the most important use of partitioning
> is "dropping a billion rows efficiently and getting the disk space
> back".
Right. The only way to make that speedy i
On Thu, Nov 10, 2011 at 10:19:02PM +0100, Dimitri Fontaine wrote:
> Now the aim would be to be able to implement the operation you describe
> by using the new segment map, which is an index pointing to sequential
> ranges of on-disk blocks where the data is known to share a common key
> range over
On Thu, Nov 10, 2011 at 1:19 PM, Dimitri Fontaine
wrote:
> Now the aim would be to be able to implement the operation you describe
> by using the new segment map, which is an index pointing to sequential
> ranges of on-disk blocks where the data is known to share a common key
> range over the colu
Jeff Janes writes:
> shouldn't it need a DBA to declare it? How is the system supposed to
> anticipate that at some point years in the future I will want to run
> the command sequence "create foo_archive as select from foo where
> year<2009; delete from foo where year<2009", or its partition-base
On Wed, Nov 9, 2011 at 1:05 PM, Dimitri Fontaine wrote:
> Thom Brown writes:
>> Whenever I cross the topic of
>> partitioning in PostgreSQL, it's always a tad embarrassing to explain
>> that it's still hacky compared to other database systems (and this
>> came up again last week), so this is of p
On 11/09/2011 04:05 PM, Dimitri Fontaine wrote:
The more I think about this problem, the more I think that the reason
why we still don't have declarative partitioning is that it basically
sucks.
I think that we don't have it because no one has ever dumped the much
larger than might be expected
On 9 November 2011 21:05, Dimitri Fontaine wrote:
> Thom Brown writes:
>> Whenever I cross the topic of
>> partitioning in PostgreSQL, it's always a tad embarrassing to explain
>> that it's still hacky compared to other database systems (and this
>> came up again last week), so this is of particu
Thom Brown writes:
> Whenever I cross the topic of
> partitioning in PostgreSQL, it's always a tad embarrassing to explain
> that it's still hacky compared to other database systems (and this
> came up again last week), so this is of particular interest to me. At
The more I think about this prob
On 9 November 2011 15:15, Robert Haas wrote:
> On Wed, Nov 9, 2011 at 9:35 AM, Jaime Casanova wrote:
>> On Wed, Nov 9, 2011 at 8:26 AM, Thom Brown wrote:
>>>
>>> So will this be revived any time soon? Were there any subsequent
>>> proposals which were posted?
>>>
>>
>> there was an updated patc
On Wed, Nov 9, 2011 at 9:35 AM, Jaime Casanova wrote:
> On Wed, Nov 9, 2011 at 8:26 AM, Thom Brown wrote:
>>
>> So will this be revived any time soon? Were there any subsequent
>> proposals which were posted?
>>
>
> there was an updated patch, you can find in this thread:
> http://archives.postg
On Wed, Nov 9, 2011 at 8:26 AM, Thom Brown wrote:
>
> So will this be revived any time soon? Were there any subsequent
> proposals which were posted?
>
there was an updated patch, you can find in this thread:
http://archives.postgresql.org/message-id/20100114181323.9a33.52131...@oss.ntt.co.jp
n
On 15 December 2009 02:31, Jaime Casanova wrote:
> On Mon, Dec 14, 2009 at 7:29 PM, Simon Riggs wrote:
>> On Fri, 2009-12-04 at 09:00 +, Simon Riggs wrote:
>>> On Fri, 2009-12-04 at 11:54 +0900, Itagaki Takahiro wrote:
>>> > Here is an update partitioning syntax patch.
>>> >
>>> > A bug repor
Robert Haas wrote:
> With respect to tab completion, ALTER TABLESPACE x currently completes
> with only "OWNER TO" or "RENAME TO"; we need to add "SET" to that
> list. My bad.
Ok, I'll go for it.
I see non-tab-completion parts are too late for 9.0.
Regards,
---
Takahiro Itagaki
NTT Open Sourc
Robert Haas writes:
> I don't think we can change this because "ALTER COLUMN SET STATISTICS"
> is not new in 8.5. We added (and then removed) "ALTER COLUMN SET
> STATISTICS DISTINCT", but that's not the same thing.
> What we COULD do is add a column option called statistics_target and
> then mak
On Sun, Jan 24, 2010 at 9:16 PM, Takahiro Itagaki
wrote:
> I found a couple of incomplete syntax when I was adjusting psql
> automatic tab completion for HEAD.
So, I'm slightly confused about whether you want to fix tab completion
or behavior, but...
> 1. We cannot specify tablespace options on
I found a couple of incomplete syntax when I was adjusting psql
automatic tab completion for HEAD.
1. We cannot specify tablespace options on "CREATE TABLESPACE"
though "ALTER TABLESPACE" supports generic options by SET (...).
2. Should we still support "ALTER COLUMN SET STATISTICS"
though
On Mon, Dec 14, 2009 at 7:29 PM, Simon Riggs wrote:
> On Fri, 2009-12-04 at 09:00 +, Simon Riggs wrote:
>> On Fri, 2009-12-04 at 11:54 +0900, Itagaki Takahiro wrote:
>> > Here is an update partitioning syntax patch.
>> >
>> > A bug reported by Marko is fixed.
>>
>> I will review and eventually
On Fri, 2009-12-04 at 09:00 +, Simon Riggs wrote:
> On Fri, 2009-12-04 at 11:54 +0900, Itagaki Takahiro wrote:
> > Here is an update partitioning syntax patch.
> >
> > A bug reported by Marko is fixed.
>
> I will review and eventually commit this, if appropriate, though it is
> 3rd in my queu
Greg Smith wrote:
> I've marked Simon as the next reviewer and expected committer on this
> patch and have updated it to "Returned with Feedback".
OK. I'll re-submit improved patches in the next commit fest.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
--
Sent via pgsql-h
Simon Riggs wrote:
I will review and eventually commit this, if appropriate, though it is
3rd in my queue and will probably not be done for at least 2 weeks,
possibly 4 weeks.
I've marked Simon as the next reviewer and expected committer on this
patch and have updated it to "Returned with Fee
On Fri, 2009-12-04 at 11:54 +0900, Itagaki Takahiro wrote:
> Here is an update partitioning syntax patch.
>
> A bug reported by Marko is fixed.
I will review and eventually commit this, if appropriate, though it is
3rd in my queue and will probably not be done for at least 2 weeks,
possibly 4 wee
Emmanuel Cecchet wrote:
> Should we add the 'WITH (...) TABLESPACE tbs' options to the syntax
> since they are supported?
Added the description.
> Do we support ALTER ... SET TABLESPACE?
DROP/ALTER PARTITION are synonyms for DROP/ALTER TABLE.
SET TABLESPACE is also supported. Added the descr
Greg Smith wrote:
I just made a few updates to
http://wiki.postgresql.org/wiki/Table_partitioning , merging in the
stuff that had been on the ToDo page and expanding the links to
discussion on this list a bit. The number of submitted patches over
the last couple of years that handle some subs
I just made a few updates to
http://wiki.postgresql.org/wiki/Table_partitioning , merging in the
stuff that had been on the ToDo page and expanding the links to
discussion on this list a bit. The number of submitted patches over the
last couple of years that handle some subset of the desired f
Emmanuel Cecchet wrote:
> I think that other databases allows the
> user to define a tablespace for each partition in the create table
> statement.
WITH and TABLESPACE clause are supported for each partition.
=# CREATE TABLE parent (...) PARTITION BY (key)
(
PARTITION child_1 VALU
Hi,
Sorry for commenting only now but I think that we need to be able to
store the partitions in different tablespaces. Even if originally the
create table creates all partitions in the same tablespace, individual
partitions should be allowed to be moved in different tablespaces using
alter t
2009/11/25 Tom Lane :
> Hitoshi Harada writes:
>> Rewriting my frame support types patch to allow any expression in
>> PRECEDING/FOLLOWING clause, I found the syntax below in PG conflicts:
>
> Yeah, we ran into that in the original WINDOW patch IIRC, and found some
> solution to it that got taken
Hitoshi Harada writes:
> Rewriting my frame support types patch to allow any expression in
> PRECEDING/FOLLOWING clause, I found the syntax below in PG conflicts:
Yeah, we ran into that in the original WINDOW patch IIRC, and found some
solution to it that got taken out again when the functionalit
Rewriting my frame support types patch to allow any expression in
PRECEDING/FOLLOWING clause, I found the syntax below in PG conflicts:
frame_extent: frame_bound { ... }
| BETWEEN frame_bound AND frame_bound { ... }
;
frame_bound: UNBOUNDED PRECEDING { ... }
| UNBOUNDED FOLLOWING { ... }
On Fri, Nov 20, 2009 at 2:08 AM, Simon Riggs wrote:
> On Thu, 2009-11-19 at 10:53 -0500, Robert Haas wrote:
>> On Thu, Nov 19, 2009 at 9:58 AM, Markus Wanner wrote:
>> > Hi,
>> >
>> > Robert Haas wrote:
>> >>
>> >> Settling on a syntax, and an internal representation for that syntax,
>> >
>> > I'
On Thu, 2009-11-19 at 10:53 -0500, Robert Haas wrote:
> On Thu, Nov 19, 2009 at 9:58 AM, Markus Wanner wrote:
> > Hi,
> >
> > Robert Haas wrote:
> >>
> >> Settling on a syntax, and an internal representation for that syntax,
> >
> > I've been under the impression that this was only about syntax. W
Peter Eisentraut writes:
> 2) I would prefer that you apply sizeof on the variable, not on the
> type. That way, the expression is independent of any type changes of
> the variable, and can be reviewed without having to scroll around for
> the variable definition.
FWIW, I think the general proje
Nikhil Sontakke writes:
>>> partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo));
>>
>> 1) Please stop casting the results of palloc and malloc. We are not
>> writing C++ here.
> I thought it was/is a good C programming practice to typecast (void *)
> always to the returning struc
On fre, 2009-11-20 at 11:14 +0530, Nikhil Sontakke wrote:
> Hi,
>
> >> > partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo));
> >
> > 1) Please stop casting the results of palloc and malloc. We are not
> > writing C++ here.
> >
>
> I thought it was/is a good C programming practice
Hi,
>> > partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo));
>
> 1) Please stop casting the results of palloc and malloc. We are not
> writing C++ here.
>
I thought it was/is a good C programming practice to typecast (void *)
always to the returning structure type!!
Regards,
Nik
On ons, 2009-11-18 at 13:52 +0900, Itagaki Takahiro wrote:
> > partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo));
>
> Oops, it should be "p"alloc. Thanks.
A very low-level comment:
1) Please stop casting the results of palloc and malloc. We are not
writing C++ here.
2) I would
On Thu, Nov 19, 2009 at 9:58 AM, Markus Wanner wrote:
> Hi,
>
> Robert Haas wrote:
>>
>> Settling on a syntax, and an internal representation for that syntax,
>
> I've been under the impression that this was only about syntax. What are the
> internal additions?
I haven't looked at it in detail, b
Hi,
Robert Haas wrote:
Settling on a syntax, and an internal representation for that syntax,
I've been under the impression that this was only about syntax. What are
the internal additions?
Generally speaking, I'd agree with Simon or even vote for doing the
internals first and add the synt
On Wed, 2009-11-18 at 13:24 +0900, Itagaki Takahiro wrote:
> Simon Riggs wrote:
>
> > Why not just wait until we have a whole patch and then apply?
>
> "A whole patch" can be written by many contributers instead of only
> one person, no? I think we need to split works for partitioning
> into se
Marko Tiikkaja wrote:
> this looks like a mistake:
> partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo));
Oops, it should be "p"alloc. Thanks.
> Maybe we should use something like
> PARTITION bar VALUES OPERATOR 0
> when the user specifies the operator?
I think we could have rea
Jaime Casanova wrote:
> > * If a table with the same name already exists when a partition
> > is created, the table is re-used as partition. This behavior
> > is required for pg_dump to be simple.
>
> i guess the table must be empty, if not we should be throw an error...
> and i actually pr
Simon Riggs wrote:
> Why not just wait until we have a whole patch and then apply?
"A whole patch" can be written by many contributers instead of only
one person, no? I think we need to split works for partitioning
into serveral parts to encourage developing it. I just did one of
the parts, "s
Marko Tiikkaja wrote:
> Jaime Casanova wrote:
> >> PARTITION name VALUES LESS THAN { range_upper | MAXVALUE }
> >>| PARTITION name VALUES IN ( list_value [,...] | DEFAULT )
> >
> > i remember someone making a comment about actually using operators
> > instead of LESS THEN and family
>
On Tue, Nov 17, 2009 at 4:31 PM, Simon Riggs wrote:
> On Thu, 2009-10-29 at 11:15 +0900, Itagaki Takahiro wrote:
>
>> I think syntax support is a good start.
>
> I don't see a syntax-only patch as being any use at all to this
> community.
>
> We go to enormous lengths in other areas to never allow
On Thu, 2009-10-29 at 11:15 +0900, Itagaki Takahiro wrote:
> I think syntax support is a good start.
I don't see a syntax-only patch as being any use at all to this
community.
We go to enormous lengths in other areas to never allow patches with
restrictions. Why would we allow a patch that is es
Jaime Casanova wrote:
* If a table with the same name already exists when a partition
is created, the table is re-used as partition. This behavior
is required for pg_dump to be simple.
i guess the table must be empty, if not we should be throw an error...
and i actually prefer some more
On Thu, Nov 12, 2009 at 5:54 AM, Itagaki Takahiro
wrote:
> I added psql and pg_dump support to Partitioning Syntax patch.
> Paritioning information can be retrieved with a new system function
> pg_get_partitiondef(parentRelid). Both psql and pg_dump use it.
>
i haven't seen the patch but:
>
> *
Hi,
I'm reviewing your patch. The patch applies without problems and the
feature works as advertised. I have yet to look at the code in detail,
but it looks sane and seems to work. However, this looks like a mistake:
partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo));
or am I
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
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
Robert Haas writes:
> IMO, the real problem is that the type interface is poorly
> encapsulated. There's way too much code that knows about the internal
> details of a type - namely, that it's a 32-bit integer modified by a
> second 32-bit integer. I think there are still places where the code
>
On Fri, 2009-10-30 at 17:39 -0400, Robert Haas wrote:
> IMO, the real problem is that the type interface is poorly
> encapsulated. There's way too much code that knows about the internal
> details of a type - namely, that it's a 32-bit integer modified by a
> second 32-bit integer. I think there
On Fri, Oct 30, 2009 at 5:16 PM, Tom Lane wrote:
> Jeff Davis writes:
>> I haven't looked at all of these places yet, so maybe a few simple
>> changes would allow us to treat typmod as a full 32 bits. Or perhaps it
>> could just be expanded to a signed 64-bit int. What do you think?
>
> Neither i
Jeff Davis writes:
> I haven't looked at all of these places yet, so maybe a few simple
> changes would allow us to treat typmod as a full 32 bits. Or perhaps it
> could just be expanded to a signed 64-bit int. What do you think?
Neither is likely to happen, and even disregarding that, I doubt pe
* Jeff Davis (pg...@j-davis.com) wrote:
> Oid is unsigned, typmod is signed. We might be able to get away with it,
> but -1 is treated specially in some places outside of the type-specific
> functions, e.g. exprTypmod().
Any negative result returned from the input handling function is
considered a
On Fri, 2009-10-30 at 19:12 +0200, Heikki Linnakangas wrote:
> Wait, it doesn't? A typmod is a 32-bit integer, like Oids. Am I missing
> something?
Oid is unsigned, typmod is signed. We might be able to get away with it,
but -1 is treated specially in some places outside of the type-specific
funct
Jeff Davis wrote:
> On Fri, 2009-10-30 at 10:03 +0200, Peter Eisentraut wrote:
>> I can't help but wonder if the period type might better be a generic
>> container for pairs of scalar, totally-ordered types.
>
> That would be ideal. However, it doesn't really look like our type
> system was built
>> PARTITION BY RANGE ( a_expr )
>> ...
>> PARTITION BY HASH ( a_expr )
>> PARTITIONS num_partitions;
> Unless someone comes up with a maintenance plan for stable hashfunctions, we
> should probably not dare look into this yet.
What would cover the common use case of per-day quals and drops ove
On Fri, 2009-10-30 at 10:03 +0200, Peter Eisentraut wrote:
> I can't help but wonder if the period type might better be a generic
> container for pairs of scalar, totally-ordered types.
That would be ideal. However, it doesn't really look like our type
system was built to handle that kind of thing
On Thu, 2009-10-29 at 11:15 +0900, Itagaki Takahiro wrote:
> I'd like to improve partitioning feature in 8.5.
Nice.
> Here is syntax I propose:
Is this the same as / similar to Oracle's syntax?
IIRC Nikhil's patch was Oracle's syntax, and I prefer having that one
instead of inventing our own
On Thu, 2009-10-29 at 15:19 -0700, Jeff Davis wrote:
> I can't help but wonder if the PERIOD type might be better for
> representing a partition range. It would make it easier to express and
> enforce the constraint that no two partition ranges overlap ;)
I can't help but wonder if the period type
Greg Stark wrote:
> >> * ALTER TABLE ... DROP [COLUMN] name [CASCADE | RESTRICT]
> >> * ALTER TABLE ... DROP PARTITION name [CASCADE | RESTRICT]
>
> Do we need a DROP PARTITION command at all? What would it even do?
Currently no. So, it would be good to treat PARTITION as
just a synonym of TA
On Thu, Oct 29, 2009 at 7:14 PM, Robert Haas wrote:
>> CREATE TABLE does not require PARTITION to be a reserved keyword,
>> but there are conflicts in ALTER TABLE ADD/DROP PARTITION:
>>
>> * ALTER TABLE ... DROP [COLUMN] name [CASCADE | RESTRICT]
>> * ALTER TABLE ... DROP PARTITION name [CASCAD
Peter Eisentraut wrote:
> On tor, 2009-10-29 at 11:15 +0900, Itagaki Takahiro wrote:
> > Range partitioning:
> > CREATE TABLE table_name ( columns )
> > PARTITION BY RANGE ( a_expr )
> > (
> > PARTITION name VALUES LESS THAN [(] const [)],
> > PARTITION name VALUES LESS THA
On Thu, Oct 29, 2009 at 9:51 PM, Itagaki Takahiro
wrote:
>
> Heikki Linnakangas wrote:
>
>> > The keyword "PARTITION" is
>> > added to the full-reserved keyword list to support ADD/DROP PARTITION.
>>
>> Any chance to avoid that? PARTITION seems like something people might
>> well use as a column
Heikki Linnakangas wrote:
> > The keyword "PARTITION" is
> > added to the full-reserved keyword list to support ADD/DROP PARTITION.
>
> Any chance to avoid that? PARTITION seems like something people might
> well use as a column or variable name. OTOH, it is reserved in SQL2008
> and SQL2003.
On Fri, 2009-10-30 at 00:10 +0200, Peter Eisentraut wrote:
> On tor, 2009-10-29 at 11:15 +0900, Itagaki Takahiro wrote:
> > Range partitioning:
> > CREATE TABLE table_name ( columns )
> > PARTITION BY RANGE ( a_expr )
> > (
> > PARTITION name VALUES LESS THAN [(] const [)],
> >
On tor, 2009-10-29 at 11:15 +0900, Itagaki Takahiro wrote:
> Range partitioning:
> CREATE TABLE table_name ( columns )
> PARTITION BY RANGE ( a_expr )
> (
> PARTITION name VALUES LESS THAN [(] const [)],
> PARTITION name VALUES LESS THAN [(] MAXVALUE [)] -- overflow partition
On Thursday 29 October 2009 18:33:22 Greg Stark wrote:
> On Thu, Oct 29, 2009 at 3:35 AM, Nikhil Sontakke
>
> wrote:
> > So +1 on solidifying the syntax first and then sorting out the other
> > minute, intricate details later..
>
> I like that idea as well but I have a concern. What will we do w
On Thu, Oct 29, 2009 at 3:35 AM, Nikhil Sontakke
wrote:
> So +1 on solidifying the syntax first and then sorting out the other
> minute, intricate details later..
I like that idea as well but I have a concern. What will we do with
pg_dump. If the PARTITION commands are just syntactic sugar for
cr
1 - 100 of 180 matches
Mail list logo
