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
Peter Eisentraut writes:
> There is a gap in the permission scheme for inheritance setups. Say you
> have this:
> CREATE TABLE persons (...);
> CREATE TABLE employees (...) INHERITS (persons);
> GRANT SELECT ON persons TO foo;
> Then user foo can extract who the employees are using
> SELECT *
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 Thu, Oct 29, 2009 at 7:17 AM, Tom Lane wrote:
> Pipelined execution would be nice but I really doubt that it's worth
> what we'd have to give up to have it. The one-at-a-time behavior will
> be simple to understand and reliable to use. Concurrent execution won't
> be either.
I think the idea
There is a gap in the permission scheme for inheritance setups. Say you
have this:
CREATE TABLE persons (...);
CREATE TABLE employees (...) INHERITS (persons);
GRANT SELECT ON persons TO foo;
Then user foo can extract who the employees are using
SELECT * FROM persons EXCEPT SELECT * FROM ONLY
On tis, 2009-09-01 at 14:29 -0400, Tom Lane wrote:
> Robert Haas writes:
> > I think we should always or never show the view definition, not sometimes.
>
> Yeah. I can live with \d not showing it and \d+ showing it --- as Peter
> already mentioned, that would be consistent with \df behavior. Ma
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 Thu, Oct 29, 2009 at 3:46 PM, Marko wrote:
> Dear,
>
> I have few suggestions about new features of postgresql.
>
> 1.Replication and clustering
>
> included in core of postgresql
There are projects being worked on in this area, and add-on products
like Slony that can be used as well. You mig
Dear,
I have few suggestions about new features of postgresql.
1.Replication and clustering
included in core of postgresql
2.other
support beter olap and data warehouse solutions.
support bulk load with c-api.
thanks
marko
All of this *also* applies to shared_preload_libraries. We also need to
be able to specify new load libraries without editing the same darn
parameter.
---
On Wed, 2009-10-28 at 22:00 +, Simon Riggs wrote:
> On Tue, 2009-10-27 at 00:38 -0400, Greg Smith wrote:
> > new feature
>
> One addition
On Thu, 2009-10-29 at 10:54 +0200, Heikki Linnakangas wrote:
> I presume you're going to need some backend support and possibly new
> syntax for some of the operations, right? That seems more urgent to
> discuss than the possible inclusion into contrib.
There are various areas that need work insid
I would like to add a temporal contrib module. The most important piece
would be adding a period data type and some support functions. Jeff
Davis and I both have temporal projects on pgFoundry, and we've been
collaborating for a while.
I presume you're going to need some backend support and po
On Thu, 2009-10-29 at 09:37 +, Richard Huxton wrote:
> There are cases where one time is genuinely unknown, and there we need
> a null.
The semantics of a period with one side NULL require a more clear
definition. I don't personally see a lot of utility in trying to support
NULL semantics, but
On Thu, 2009-10-29 at 00:31 -0700, Scott Bailey wrote:
> Nulls - A common use case for periods is for modeling valid time. Often
> the end point is not known. For instance, you know when an employee has
> been hired but the termination time typically wouldn't be known ahead of
> time. We can ei
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
Hi,
Sergej Galkin writes:
> 1) where could I know the prototypes of such functions as union,
> pentaly and etc. And to read more detally than in PostgreSql
> documentation ?
Have you read that yet?
http://www.postgresql.org/docs/8.4/interactive/gist-implementation.html
> 2) How could I save i
"Joshua D. Drake" writes:
> In regards to parsing files in a directory. It makes sense. Why the
> implementation is so difficult is beyond me. Can't we just look at
> Apache and say, "Gee, it may not be perfect but it does everything we
> need, let's use their implementation."?
Reading files in a
On Thu, 2009-10-29 at 09:32 -0400, Tom Lane wrote:
> Hannu Krosing writes:
> > Or maybe we could just extract the hashes form some version of stock
> > postgresql (say 8.3) and then make those available in contrib under the
> > name "stable_hashes" ?
>
> A better name would be "wishful_thinking"
Itagaki Takahiro 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.
--
Heikki Linn
On Thu, Oct 29, 2009 at 11:38 AM, Tom Lane wrote:
> Robert Haas writes:
>> Another option would be to introduce a section syntax, something like
>> what M$ does. We could define a line that contains just [foo] to mean
>> "define foo as a custom variable class and automatically put all the
>> res
Hello to all,
I'm a young programmer student, and I would like to realize TPR-index on
Postgresql system. Of course I want to use GiST template, rather than
writing core :)
I have some questions, and I would be very grateful if anybody answers my
question.
1) where could I know the prototypes of su
Tom Lane wrote:
Andrew Dunstan writes:
The whole config file is a joke. We'd never do it the way we do if we
were designing it from scratch,
Why not, pray tell? We did design it from scratch, once upon a time,
and I don't see that the design is so obviously broken that we'd not
do
On Thu, 2009-10-29 at 11:42 -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > The whole config file is a joke. We'd never do it the way we do if we
> > were designing it from scratch,
>
> Why not, pray tell? We did design it from scratch, once upon a time,
> and I don't see that the design is
* Peter Eisentraut (pete...@gmx.net) wrote:
> On Wed, 2009-10-28 at 15:11 +0100, Anders Steinlein wrote:
> > Is there any interest in expanding \dn+ to show schema size, similar
> > to table sizes using \dt+ in 8.4? We use separate schemas for each
> > user, so this would allow us to quickly lo
Andrew Dunstan writes:
> The whole config file is a joke. We'd never do it the way we do if we
> were designing it from scratch,
Why not, pray tell? We did design it from scratch, once upon a time,
and I don't see that the design is so obviously broken that we'd not
do the same thing if startin
Robert Haas writes:
> Another option would be to introduce a section syntax, something like
> what M$ does. We could define a line that contains just [foo] to mean
> "define foo as a custom variable class and automatically put all the
> rest of the settings in this section into that namespace".
Joshua D. Drake wrote:
On Thu, 2009-10-29 at 12:31 +, Thom Brown wrote:
2009/10/29 Andrew Dunstan :
Why not allow something like += or .= instead of the = to denote appending
to a list?
custom_variable_classes += 'x'
seems a whole lot nicer to me.
I would see tha
On Thu, Oct 29, 2009 at 9:44 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Anyway, it seems to me a whole lot better than inventing a new thing
>> that makes "custom_variable_class" as something to append to
>> "custom_variable_classes". If you're going to insist on using "append
>> foo = 'x'"
On Thu, 2009-10-29 at 12:31 +, Thom Brown wrote:
> 2009/10/29 Andrew Dunstan :
> > Why not allow something like += or .= instead of the = to denote appending
> > to a list?
> >
> > custom_variable_classes += 'x'
> >
> > seems a whole lot nicer to me.
> >
>
> I would see that as making the c
>>
>>
>
> Really, they don't know any Perl or Python or Java either? Maybe.
>
> Anyway, it seems to me a whole lot better than inventing a new thing that
> makes "custom_variable_class" as something to append to
> "custom_variable_classes". If you're going to insist on using "append foo =
> 'x'" a
Thom Brown writes:
> custom_variable_classes = 'x'
> custom_variable_classes += 'y'
> custom_variable_classes = 'z'
>
> That would result in the first 2 assignments being undone.
That's why I don't see how having as many files as you want to *for tool
based* configuration is a improvement of any
Robert Haas writes:
> To be honest, I'm not entirely comfortable with either behavior.
> Pipelining a delete out of one table into an insert into another table
> seems VERY useful to me, and I'd like us to have a way to do that. On
> the other hand, in more complex cases, the fact that the effect
On Thu, 2009-10-29 at 09:32 -0400, Tom Lane wrote:
> Hannu Krosing writes:
> > Or maybe we could just extract the hashes form some version of stock
> > postgresql (say 8.3) and then make those available in contrib under the
> > name "stable_hashes" ?
>
> A better name would be "wishful_thinking"
On 29 Oct 2009, at 02:15, Itagaki Takahiro wrote:
I'd like to improve partitioning feature in 8.5.
Kedar-san's previous work is wonderful, but I cannot see any updated
patch.
http://archives.postgresql.org/message-id/bd8134a40906080702s96c90a9q3bbb581b9bd0d...@mail.gmail.com
So, I'll take o
Andrew Dunstan writes:
> Anyway, it seems to me a whole lot better than inventing a new thing
> that makes "custom_variable_class" as something to append to
> "custom_variable_classes". If you're going to insist on using "append
> foo = 'x'" at least let it apply to the list that is actually b
On Thu, Oct 29, 2009 at 11:19 AM, Peter Eisentraut wrote:
> On Wed, 2009-10-28 at 15:11 +0100, Anders Steinlein wrote:
> > Is there any interest in expanding \dn+ to show schema size, similar
> > to table sizes using \dt+ in 8.4? We use separate schemas for each
> > user, so this would allow us t
Hannu Krosing writes:
> Or maybe we could just extract the hashes form some version of stock
> postgresql (say 8.3) and then make those available in contrib under the
> name "stable_hashes" ?
A better name would be "wishful_thinking" ... contrib does not have
control over some of the main risk fa
On Wed, 2009-10-28 at 15:11 +0100, Anders Steinlein wrote:
> Is there any interest in expanding \dn+ to show schema size, similar
> to table sizes using \dt+ in 8.4? We use separate schemas for each
> user, so this would allow us to quickly look up the sizes of each
> user's data.
A schema d
Pavel Stehule wrote:
2009/10/29 Andrew Dunstan :
Pavel Stehule wrote:
2009/10/27 Simon Riggs :
On Tue, 2009-10-27 at 00:38 -0400, Greg Smith wrote:
new feature
One additional point that would be useful is a way to match up the usage
of custom_variable_
2009/10/29 Andrew Dunstan :
>
>
> Pavel Stehule wrote:
>>
>> 2009/10/27 Simon Riggs :
>>
>>>
>>> On Tue, 2009-10-27 at 00:38 -0400, Greg Smith wrote:
>>>
new feature
>>>
>>> One additional point that would be useful is a way to match up the usage
>>> of custom_variable_classes with t
2009/10/29 Andrew Dunstan :
>
>
> Pavel Stehule wrote:
>>
>> 2009/10/27 Simon Riggs :
>>
>>>
>>> On Tue, 2009-10-27 at 00:38 -0400, Greg Smith wrote:
>>>
new feature
>>>
>>> One additional point that would be useful is a way to match up the usage
>>> of custom_variable_classes with t
Pavel Stehule wrote:
2009/10/27 Simon Riggs :
On Tue, 2009-10-27 at 00:38 -0400, Greg Smith wrote:
new feature
One additional point that would be useful is a way to match up the usage
of custom_variable_classes with this new style of .conf file processing.
At the moment if yo
Le dimanche 25 octobre 2009 10:08:33, Peter Eisentraut a écrit :
> On lör, 2009-10-24 at 13:32 -0400, Greg Smith wrote:
> > Regardless, the UI I was hoping for was to make the default
> > postgresql.conf file end with a line like this:
> >
> > directory 'conf'
>
> I think something like is this is
On Wed, 2009-10-28 at 09:39 -0700, Greg Stark wrote:
> On Wed, Oct 28, 2009 at 7:33 AM, Alvaro Herrera
> wrote:
> > Greg Smith escribió:
> >
> >> This sounds familiar...oh, that's right, this is almost the same
> >> algorithm pgtune uses. And it sucks,
>
> It's also a blatant violation of packag
On Tue, 2009-10-27 at 20:40 -0700, Josh Berkus wrote:
> If you require that a tool (or SET PERISTENT) parse through a file in
> order to change one setting, then you've just doubled or tripled the
> code size of the tool, as well as added a host of failure conditions
> which wouldn't have existed o
Hi,
> So, I'll take over the work if there are no ones to do it.
> I'm thinking to add syntax support first. Table partitioning was
> proposed many times, but it is still not applied into core.
> The reason is it is too difficult to make perfect partitioning
> feature at once. I think syntax suppo
Heikki Linnakangas wrote:
> Scott Bailey wrote:
>> I would like to add a temporal contrib module.
> I'm very pleased to see people working on temporal issues, BTW!
Me too - common use-case and difficult to handle without the right
types/operators.
>> Nulls - A common use case for periods is fo
On Friday 30 November at 1200 GMT, the server that hosts our primary
FTP server, GIT server and one of the website mirrors will be moved to
a new data center. Downtime is expected to be two to three hours.
Apologies for any inconvenience this may cause.
--
Dave Page
EnterpriseDB UK: http://www.e
Scott Bailey wrote:
> I would like to add a temporal contrib module. The most important piece
> would be adding a period data type and some support functions. Jeff
> Davis and I both have temporal projects on pgFoundry, and we've been
> collaborating for a while.
I presume you're going to need som
On Thu, 2009-10-29 at 09:47 +0200, Peter Eisentraut wrote:
> On Wed, 2009-10-28 at 12:51 -0700, Jeff Davis wrote:
> > Trying to develop and document a set of standardized, stable hash
> > functions covering a wide range of possible use cases sounds like it may
> > be better served by an extension.
Hello
I got a possibility to continue on GROUPING SETS see
http://wiki.postgresql.org/wiki/Grouping_Sets
My last patch was based on an sharing functionality with non recursive
CTE. I would to recapitulate all options here and I would to prepare
this patch for next commitfest.
a) using actualised
2009/10/29 Scott Bailey :
> I would like to add a temporal contrib module. The most important piece
> would be adding a period data type and some support functions. Jeff Davis
> and I both have temporal projects on pgFoundry, and we've been collaborating
> for a while. But there are some areas we'd
On Wed, 2009-10-28 at 12:51 -0700, Jeff Davis wrote:
> Trying to develop and document a set of standardized, stable hash
> functions covering a wide range of possible use cases sounds like it may
> be better served by an extension.
I suspect that some of the participants in this thread have PL/Pro
I would like to add a temporal contrib module. The most important piece
would be adding a period data type and some support functions. Jeff
Davis and I both have temporal projects on pgFoundry, and we've been
collaborating for a while. But there are some areas we'd like to get
some advice on.
2009/10/27 Simon Riggs :
> On Tue, 2009-10-27 at 00:38 -0400, Greg Smith wrote:
>> new feature
>
> One additional point that would be useful is a way to match up the usage
> of custom_variable_classes with this new style of .conf file processing.
>
> At the moment if you wish to add a custom variab
60 matches
Mail list logo
