On Mon, 2009-11-23 at 10:24 -0500, Emmanuel Cecchet wrote:
> But it looks like it is a waste of everybody's time to continue this
> discussion further. Just move the patch to the rejected patches and
> let's wait for Itagaki's implementation.
Emmanuel, please try to work together with Itagaki s
On Mon, 2009-11-23 at 18:31 -0500, Greg Smith wrote:
> Robert Haas wrote:
> > I'm fuzzy on what problem this is attempting to solve... as mentioned
> > in the above guidelines, it's usually good to start with some design
> > discussions before writing/submitting code.
> This has been through some
Hannu Krosing wrote:
> Even though this patch will not get in, most of the effort in developing
> it is not actual coding, but familiarizing yourself with the other code
> involved.
I just edited a wiki page for this discussion.
I hope it can be a help.
http://wiki.postgresql.org/wiki/Table_pa
On Mon, 2009-11-23 at 16:25 -0800, Daniel Farina wrote:
> On Mon, Nov 23, 2009 at 4:20 PM, Tom Lane wrote:
> > pgsql-hackers had some preliminary discussions a couple months back
> > on refactoring COPY to allow things like this --- see the thread
> > starting here:
> > http://archives.postgresql.
On Sun, 2009-11-22 at 18:51 -0500, Tom Lane wrote:
> Craig Ringer writes:
> > I do think this comes up often enough that a built-in trigger "update
> > named column with result of expression on insert" trigger might be
> > desirable.
>
> There's something of the sort in contrib already, I believe
On Tue, Nov 24, 2009 at 12:29 AM, Hannu Krosing wrote:
> COPY stdin TO udf();
If stdin becomes (is?) a legitimate source of records, then this patch
will Just Work.
The patch is already quite useful in the COPY (SELECT ...) TO FUNCTION
... scenario.
> COPY udf() FROM stdin;
This is unaddressed
On Tue, Nov 24, 2009 at 12:38 AM, Hannu Krosing wrote:
> COPY func(rowtype) FROM stdin;
I didn't consider rowtype...I did consider a type list, such as:
COPY func(typea, typeb, typec) FROM ...
Which would then operate just like a table, but be useless for the
data-cleaning case, and would not a
2009/11/24 Hannu Krosing
> On Sun, 2009-11-22 at 18:51 -0500, Tom Lane wrote:
> > Craig Ringer writes:
> > > I do think this comes up often enough that a built-in trigger "update
> > > named column with result of expression on insert" trigger might be
> > > desirable.
> >
> > There's something o
Hello
I thing, so this patch is maybe good idea. I am missing better
function specification. Specification by name isn't enough - we can
have a overloaded functions. This syntax doesn't allow to use explicit
cast - from my personal view, the syntax is ugly - with type
specification we don't need t
On Tue, 2009-11-24 at 17:30 +0900, Itagaki Takahiro wrote:
> Hannu Krosing wrote:
>
> > Even though this patch will not get in, most of the effort in developing
> > it is not actual coding, but familiarizing yourself with the other code
> > involved.
>
> I just edited a wiki page for this discu
On Tue, Nov 24, 2009 at 2:10 AM, Pavel Stehule wrote:
> Hello
>
> I thing, so this patch is maybe good idea. I am missing better
> function specification. Specification by name isn't enough - we can
> have a overloaded functions. This syntax doesn't allow to use explicit
> cast - from my personal
On Tue, 2009-11-24 at 02:37 -0800, Daniel Farina wrote:
> On Tue, Nov 24, 2009 at 2:10 AM, Pavel Stehule
> wrote:
> > Hello
> >
> > I thing, so this patch is maybe good idea. I am missing better
> > function specification. Specification by name isn't enough - we can
> > have a overloaded function
On Tue, Nov 24, 2009 at 2:50 AM, Hannu Krosing wrote:
> Can't you use existing aggregate function design ?
>
> CREATE AGGREGATE name ( input_data_type [ , ... ] ) (
> SFUNC = sfunc,
> STYPE = state_data_type
> [ , FINALFUNC = ffunc ]
> [ , INITCOND = initial_condition ]
> [ , SORTOP
On Tue, Nov 24, 2009 at 2:51 AM, Daniel Farina wrote:
> On Tue, Nov 24, 2009 at 2:50 AM, Hannu Krosing wrote:
>> Can't you use existing aggregate function design ?
>>
>> CREATE AGGREGATE name ( input_data_type [ , ... ] ) (
>> SFUNC = sfunc,
>> STYPE = state_data_type
>> [ , FINALFUNC =
On Tue, 2009-11-24 at 09:46 +, Thom Brown wrote:
> 2009/11/24 Hannu Krosing
> On Sun, 2009-11-22 at 18:51 -0500, Tom Lane wrote:
> > Craig Ringer writes:
> > > I do think this comes up often enough that a built-in
> trigger "update
> > > named column wi
On Tue, 2009-11-24 at 02:56 -0800, Daniel Farina wrote:
> On Tue, Nov 24, 2009 at 2:51 AM, Daniel Farina wrote:
> > On Tue, Nov 24, 2009 at 2:50 AM, Hannu Krosing
> > wrote:
> >> Can't you use existing aggregate function design ?
> >>
> >> CREATE AGGREGATE name ( input_data_type [ , ... ] ) (
>
On Tue, Nov 24, 2009 at 3:25 AM, Hannu Krosing wrote:
> On Tue, 2009-11-24 at 02:56 -0800, Daniel Farina wrote:
>> On Tue, Nov 24, 2009 at 2:51 AM, Daniel Farina wrote:
>> > On Tue, Nov 24, 2009 at 2:50 AM, Hannu Krosing
>> > wrote:
>> >> Can't you use existing aggregate function design ?
>> >>
I think you'll need to work on that. A WHERE qual shouldn't imply a sort
order. You'll have to teach the planner how to use the index to speed up
a query in the first form.
Of course, right now it is a working prototype.
1. KNNGiST is about 5% slower than GiST on non-knn search queries, like
On Sat, Nov 21, 2009 at 08:29, Magnus Hagander wrote:
> 2009/11/20 Peter Eisentraut :
>> On fre, 2009-11-20 at 08:39 +0100, Magnus Hagander wrote:
>>> 2009/11/20 Peter Eisentraut :
>>> > On fre, 2009-11-20 at 02:41 +0100, Magnus Hagander wrote:
>>> >> Is there any actual reason why we are building
Teodor Sigaev wrote:
>>> 1. KNNGiST is about 5% slower than GiST on non-knn search queries, like
>>> contains or contained by, because of some overhead of new algorithm of
>>> tree traversal
>>
>> Is it possible to use the regular GiST traversal algorithm on a
>> KNNGiST-tree, when performing r
2009/11/24 Daniel Farina :
> On Tue, Nov 24, 2009 at 2:10 AM, Pavel Stehule
> wrote:
>> Hello
>>
>> I thing, so this patch is maybe good idea. I am missing better
>> function specification. Specification by name isn't enough - we can
>> have a overloaded functions. This syntax doesn't allow to us
On Tue, Nov 24, 2009 at 4:37 AM, Pavel Stehule wrote:
> 2009/11/24 Daniel Farina :
>> On Tue, Nov 24, 2009 at 2:10 AM, Pavel Stehule
>> wrote:
>>> Hello
>>>
>>> I thing, so this patch is maybe good idea. I am missing better
>>> function specification. Specification by name isn't enough - we can
On Tue, 2009-11-24 at 03:48 -0800, Daniel Farina wrote:
> On Tue, Nov 24, 2009 at 3:25 AM, Hannu Krosing wrote:
> > On Tue, 2009-11-24 at 02:56 -0800, Daniel Farina wrote:
> >> On Tue, Nov 24, 2009 at 2:51 AM, Daniel Farina wrote:
> >> > On Tue, Nov 24, 2009 at 2:50 AM, Hannu Krosing
> >> > wro
2009/11/24 Daniel Farina :
> On Tue, Nov 24, 2009 at 4:37 AM, Pavel Stehule
> wrote:
>> 2009/11/24 Daniel Farina :
>>> On Tue, Nov 24, 2009 at 2:10 AM, Pavel Stehule
>>> wrote:
Hello
I thing, so this patch is maybe good idea. I am missing better
function specification. Speci
On Tue, 2009-11-24 at 05:00 -0800, Daniel Farina wrote:
> On Tue, Nov 24, 2009 at 4:37 AM, Pavel Stehule
> wrote:
> > then syntax should be:
> >
> > COPY table TO streamname(parameters)
> >
> > COPY table TO filestream('/tmp/foo.dta') ...
> > COPY table TO dblinkstream(connectionstring) ...
You
Magnus Hagander writes:
> ISTM that it should be as simple as the attached patch. Seems to work
> for me :-) But I'm no autoconf guru, so maybe I missed something?
This patch sort of begs the question "what about enable-thread-safety-force?"
That looks even more like a wart now than it did before
On Mon, Nov 23, 2009 at 8:46 PM, Greg Smith wrote:
> You know how people complain about how new contributors are treated here?
> Throwing out comments like this, that come off as belittling to other
> people's work, doesn't help. All I was suggesting was that Dan wasn't
> developing this in comp
2009/11/24 Hannu Krosing :
> On Tue, 2009-11-24 at 05:00 -0800, Daniel Farina wrote:
>> On Tue, Nov 24, 2009 at 4:37 AM, Pavel Stehule
>> wrote:
>
>> > then syntax should be:
>> >
>> > COPY table TO streamname(parameters)
>> >
>> > COPY table TO filestream('/tmp/foo.dta') ...
>> > COPY table TO d
On Mon, Nov 23, 2009 at 9:37 PM, Andrew Dunstan wrote:
>
>
> Greg Smith wrote:
>>
>> I haven't heard anything from Andrew about ragged CVS import either. I
>> think that ultimately those features are useful, but just exceed what the
>> existing code could be hacked to handle cleanly.
>
> The patc
Itagaki Takahiro wrote:
I just edited a wiki page for this discussion.
I hope it can be a help.
http://wiki.postgresql.org/wiki/Table_partitioning
I guess the problem of handling user triggers is still open.
If we allow triggers on partitions, badly written logic could lead to
infinite loops
On Sat, Nov 21, 2009 at 12:49:33PM -0800, Mark Richardson wrote:
> I'm pretty sure the problem I found is related to this, but I found that ecpg
> doesn't process booleans correctly- this was in a old version of postgres (I
> think it was 7.4.2). I traced it down in the code, and there is a sectio
On Tue, Nov 24, 2009 at 03:12:43PM +0900, KaiGai Kohei wrote:
> Itagaki Takahiro wrote:
> > * CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...')
> > Is the syntax " SECURITY_CONTEXT" natural in English?
>
> We need to put a reserved token, such as "AS", prior to the SECURITY_CONTEXT
> to
I've started work on the enhancements to plperl I outlined on pg-general
(XXX thread)
I have a working implementation of those changes, plus some performance
enhancements, that I'm now re-working into a clean set of tested and
polished patches.
This patch is a first step that doesn't add any extra
Tim Bunce writes:
> The next step I plan is to move the large multi-line string literal
> macros (PERLBOOT, SAFE_OK etc) into external perl code files.
> That'll make refactoring, extending and maintaining that perl
> code far simpler.
That does not seem like it accomplishes anything from the use
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 { ... }
Andrew Dunstan wrote:
> Part of the motivation for allowing inline blocks was to allow for
> conditional logic. So you can do things like:
>
> DO $$
>
> begin
> if not exists (select 1 from pg_tables
> where schemaname = 'foo'
> and tablenam
Hi there,
I have problem with CVS HEAD (noticed a week or so ago) -
psql -l show garbage instead of -|+. Looks, like utf-8 symbols used
instead that ascii characters.
List of databases
NameБ■┌ Owner Б■┌ Encoding Б■┌ Collation Б■┌Ct
"Kevin Grittner" writes:
> So we're conceding that this is a valid need and people will now have
> a way to meet it. Is the argument against having CINE syntax that it
> would be more prone to error than the above, or that the code would be
> so large and complex as to create a maintenance burden
Tom Lane wrote:
> The argument against CINE is that it's unsafe.
By no means rhetorically, is that based on the assumption that the
statement would not validate that the existing object (if any) matches
the supplied definition?
> The fragment proposed by Andrew is no safer, of course, but it
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
Oleg Bartunov writes:
> I have problem with CVS HEAD (noticed a week or so ago) -
> psql -l show garbage instead of -|+. Looks, like utf-8 symbols used
> instead that ascii characters.
Hm, you only see it for -l and not for all tabular output? That's
a bit strange.
rega
On Tue, 24 Nov 2009, Tom Lane wrote:
Oleg Bartunov writes:
I have problem with CVS HEAD (noticed a week or so ago) -
psql -l show garbage instead of -|+. Looks, like utf-8 symbols used
instead that ascii characters.
Hm, you only see it for -l and not for all tabular output? That's
a bit str
On Tue, Nov 24, 2009 at 12:28 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> So we're conceding that this is a valid need and people will now have
>> a way to meet it. Is the argument against having CINE syntax that it
>> would be more prone to error than the above, or that the code would be
"Kevin Grittner" writes:
> Tom Lane wrote:
>> The argument against CINE is that it's unsafe.
> By no means rhetorically, is that based on the assumption that the
> statement would not validate that the existing object (if any) matches
> the supplied definition?
If it did so, that would be outs
Oleg Bartunov writes:
> On Tue, 24 Nov 2009, Tom Lane wrote:
>> Hm, you only see it for -l and not for all tabular output? That's
>> a bit strange.
> yes, I'm surprising myself. Teodor has no problem, but he is under FreeBSD,
> while I use slackware linux. Here is ldd output.
What's your local
On Tue, 24 Nov 2009, Tom Lane wrote:
Oleg Bartunov writes:
On Tue, 24 Nov 2009, Tom Lane wrote:
Hm, you only see it for -l and not for all tabular output? That's
a bit strange.
yes, I'm surprising myself. Teodor has no problem, but he is under FreeBSD,
while I use slackware linux. Here is
Robert Haas writes:
> On Tue, Nov 24, 2009 at 12:28 PM, Tom Lane wrote:
>> But actually I thought we had more or less concluded that CREATE OR
>> REPLACE LANGUAGE would be acceptable (perhaps only if it's given
>> without any extra args?).
> I'm not sure there's any value in that restriction - s
Oleg Bartunov writes:
> On Tue, 24 Nov 2009, Tom Lane wrote:
>> What's your locale environment? ("env | grep ^L" would help.)
> LC_COLLATE=ru_RU.KOI8-R
> LANG=C
> LC_CTYPE=ru_RU.KOI8-R
Hmm, I can duplicate the fact that psql -l uses utf8 characters
(because it connects to the postgres DB which
On tis, 2009-11-24 at 21:32 +0300, Oleg Bartunov wrote:
> On Tue, 24 Nov 2009, Tom Lane wrote:
>
> > Oleg Bartunov writes:
> >> On Tue, 24 Nov 2009, Tom Lane wrote:
> >>> Hm, you only see it for -l and not for all tabular output? That's
> >>> a bit strange.
> >
> >> yes, I'm surprising myself. T
On Tue, 24 Nov 2009, Tom Lane wrote:
Oleg Bartunov writes:
On Tue, 24 Nov 2009, Tom Lane wrote:
What's your locale environment? ("env | grep ^L" would help.)
LC_COLLATE=ru_RU.KOI8-R
LANG=C
LC_CTYPE=ru_RU.KOI8-R
Hmm, I can duplicate the fact that psql -l uses utf8 characters
(because it
On Tue, Nov 24, 2009 at 11:34 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Nov 24, 2009 at 12:28 PM, Tom Lane wrote:
>>> But actually I thought we had more or less concluded that CREATE OR
>>> REPLACE LANGUAGE would be acceptable (perhaps only if it's given
>>> without any extra args?).
On Tue, 24 Nov 2009, Peter Eisentraut wrote:
On tis, 2009-11-24 at 21:32 +0300, Oleg Bartunov wrote:
On Tue, 24 Nov 2009, Tom Lane wrote:
Oleg Bartunov writes:
On Tue, 24 Nov 2009, Tom Lane wrote:
Hm, you only see it for -l and not for all tabular output? That's
a bit strange.
yes, I'm
Tom Lane wrote:
> If it did so, that would be outside the apparent meaning of the
> command, which is to do nothing if an object of that name exists.
> That's why we've gone with CREATE OR REPLACE instead.
I think that "fail on existence of an object conflicting with given
definition" is behav
Oleg Bartunov writes:
> why 8.4 has no real problem ?
Because we never tried to use utf8 table decoration before. This
is collateral damage from Roger Leigh's recent patches.
The problem is evidently that Oleg is depending on ~/.psqlrc to
set client_encoding the way he wants it, but that file
On tis, 2009-11-24 at 21:55 +0300, Oleg Bartunov wrote:
> > Seems like a mismatch between client encoding and actual locale
> > environment.
>
> why 8.4 has no real problem ?
Because table formatting with Unicode characters is a new feature.
Anyway, that patch to set the client encoding automat
Peter Eisentraut writes:
> Anyway, that patch to set the client encoding automatically from the
> locale sounds even more useful now.
I think you're being overoptimistic to assume that that's going to
eliminate the issue. It might patch things for Oleg's particular
configuration; but the real pr
Scott Marlowe writes:
> On Tue, Nov 24, 2009 at 11:34 AM, Tom Lane wrote:
>> The point would be to reduce the risk that you're changing the language
>> definition in a surprising way. Extra args would imply that you're
>> trying to install a non-default definition of the language.
> But if you'
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Yes, I'd expect the user to custom-code it, because it's not clear
>> exactly which properties the script would be depending on and which
>> ones it's okay to allow to vary. To take just one example, is it
>> okay if the object ownership is different
On Tue, Nov 24, 2009 at 2:07 PM, Kevin Grittner
wrote:
> Tom Lane wrote:
>
>> If it did so, that would be outside the apparent meaning of the
>> command, which is to do nothing if an object of that name exists.
>> That's why we've gone with CREATE OR REPLACE instead.
>
> I think that "fail on exi
On Tue, Nov 24, 2009 at 11:57:06AM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > The next step I plan is to move the large multi-line string literal
> > macros (PERLBOOT, SAFE_OK etc) into external perl code files.
> > That'll make refactoring, extending and maintaining that perl
> > code far sim
On Tue, 24 Nov 2009, Tom Lane wrote:
Oleg Bartunov writes:
why 8.4 has no real problem ?
Because we never tried to use utf8 table decoration before. This
is collateral damage from Roger Leigh's recent patches.
The problem is evidently that Oleg is depending on ~/.psqlrc to
set client_enco
Oleg Bartunov writes:
> what's benefit of using linestyle=unicode ? I like old ASCII style
> for console.
Well, I have to grant that it looks pretty spiffy on a unicode-enabled
display. Whether that's enough reason to risk breaking things for
people with non-unicode-enabled displays is certainly
On Tue, 24 Nov 2009, Tom Lane wrote:
Oleg Bartunov writes:
what's benefit of using linestyle=unicode ? I like old ASCII style
for console.
Well, I have to grant that it looks pretty spiffy on a unicode-enabled
display. Whether that's enough reason to risk breaking things for
people with non
On Tue, Nov 24, 2009 at 4:49 PM, Oleg Bartunov wrote:
> On Tue, 24 Nov 2009, Tom Lane wrote:
>
>> Oleg Bartunov writes:
>>>
>>> what's benefit of using linestyle=unicode ? I like old ASCII style
>>> for console.
>>
>> Well, I have to grant that it looks pretty spiffy on a unicode-enabled
>> displ
On Tue, Nov 24, 2009 at 02:19:27PM -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > Anyway, that patch to set the client encoding automatically from the
> > locale sounds even more useful now.
>
> I think you're being overoptimistic to assume that that's going to
> eliminate the issue. It m
Ross J. Reedstrom wrote:
On Tue, Nov 24, 2009 at 03:12:43PM +0900, KaiGai Kohei wrote:
Itagaki Takahiro wrote:
* CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...')
Is the syntax " SECURITY_CONTEXT" natural in English?
We need to put a reserved token, such as "AS", prior to the SECURI
Roger Leigh writes:
> On Tue, Nov 24, 2009 at 02:19:27PM -0500, Tom Lane wrote:
>> I wonder whether the most prudent solution wouldn't be to prevent
>> default use of linestyle=unicode if ~/.psqlrc hasn't been read.
> This problem is caused when there's a mismatch between the
> client encoding an
On Tue, Nov 24, 2009 at 05:43:00PM -0500, Tom Lane wrote:
> Roger Leigh writes:
> > On Tue, Nov 24, 2009 at 02:19:27PM -0500, Tom Lane wrote:
> >> I wonder whether the most prudent solution wouldn't be to prevent
> >> default use of linestyle=unicode if ~/.psqlrc hasn't been read.
>
> > This prob
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
On Sat, 2009-11-21 at 20:20 +0200, Heikki Linnakangas wrote:
> That causes some headaches for Hot Standby
I say leave HS as it is and we can clean up when we do the VFectomy.
It isn't really a headache, the code works easily enough. I agree its
ugly and it should eventually be removed.
Let's no
On Sat, 2009-11-21 at 23:00 +0200, Heikki Linnakangas wrote:
> Tom Lane wrote:
> > Heikki Linnakangas writes:
> >> Tom Lane wrote:
> >>> There's no equivalent of XLogArchivingActive()?
> >
> >> XLogArchivingMode() == false enables us to skip WAL-logging in
> >> operations like CLUSTER or COPY, wh
KaiGai Kohei wrote:
> Ross J. Reedstrom wrote:
>> On Tue, Nov 24, 2009 at 03:12:43PM +0900, KaiGai Kohei wrote:
>>> Itagaki Takahiro wrote:
* CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...')
Is the syntax " SECURITY_CONTEXT" natural in English?
>>> We need to put a reserved to
Simon Riggs writes:
> Tom Lane wrote:
>> There's no equivalent of XLogArchivingActive()?
> We've tried hard to have it "just work". But I wonder whether we should
> have a parameter to allow performance testing on the master? If nobody
> finds any issues then we can remove it again, or at least m
On Mon, 2009-11-23 at 20:44 +0300, Teodor Sigaev wrote:
> Old way:
> SELECT coordinates, (coordinates <-> '5.0,5.0'::point) AS dist FROM
> spots
> order by dist asc LIMIT 10;
>
> Time: 1024.242 ms
>
> knn-search:
> SELECT coordinates, (coordinates <-> '5.0,5.0'::point) AS dist FROM
> spots
> WHER
Emmanuel Cecchet wrote:
> I guess the problem of handling user triggers is still open.
> If we allow triggers on partitions, badly written logic could lead to
> infinite loops in routing.
Infinite loops are not a partition-related problem, no?
We can also find infinite loops in user defined fu
On Tue, 2009-11-24 at 00:54 -0800, Daniel Farina wrote:
> On Tue, Nov 24, 2009 at 12:29 AM, Hannu Krosing wrote:
> > COPY stdin TO udf();
>
> If stdin becomes (is?) a legitimate source of records, then this patch
> will Just Work.
>
STDIN is a source of bytes representing a set of records. Curr
KaiGai Kohei wrote:
> > CREATE TABLE tbl (...) SECURITY CONTEXT '...'
> > * CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...')
>
> We need to put a reserved token, such as "AS", prior to the SECURITY_CONTEXT
> to avoid syntax conflicts to "DEFAULT b_expr" option.
There might be anoth
On Wed, Nov 25, 2009 at 2:10 AM, Tom Lane wrote:
> As long as there's not anything the master actually does differently
> then I can't see where there'd be any performance testing to do. What's
> bothering me about this is that it seems likely that we'll find places
> where the master has to do t
Greg Stark writes:
> Well the only thing that's been discussed is having vacuum require a
> minimum age before considering a transaction visible to all to reduce
> the chance of conflicts on cleanup records.
[ shrug... ] Call me Cassandra. I am not concerned about what has or
has not been discu
Itagaki Takahiro wrote:
Emmanuel Cecchet wrote:
I guess the problem of handling user triggers is still open.
If we allow triggers on partitions, badly written logic could lead to
infinite loops in routing.
Infinite loops are not a partition-related problem, no?
We can also find infin
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
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
Itagaki Takahiro wrote:
> KaiGai Kohei wrote:
>
>>> CREATE TABLE tbl (...) SECURITY CONTEXT '...'
>>> * CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...')
>> We need to put a reserved token, such as "AS", prior to the SECURITY_CONTEXT
>> to avoid syntax conflicts to "DEFAULT b_expr" opt
On Tue, 2009-11-24 at 14:39 +0100, Pavel Stehule wrote:
> a) good designed C API like:
>
>initialise_functions(fcinfo) -- std fcinfo
>consument_process_tuple(fcinfo) -- gets standard row -- Datum
> dvalues[] + Row description
>producent_process_tuple(fcinfo) -- returns standard row -
Jeff Davis writes:
> Don't you still need the functions to accept an argument of type
> internal? Otherwise, we lose the ability to copy a buffer to the dblink
> connection, which was the original motivation.
If you do that, then there is no possibility of ever using this feature
except with C-co
2009/11/25 Jeff Davis :
> On Tue, 2009-11-24 at 14:39 +0100, Pavel Stehule wrote:
>> a) good designed C API like:
>>
>> initialise_functions(fcinfo) -- std fcinfo
>> consument_process_tuple(fcinfo) -- gets standard row -- Datum
>> dvalues[] + Row description
>> producent_process_tuple(fci
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
On Tue, Nov 24, 2009 at 8:45 PM, Pavel Stehule wrote:
> It depends on design. I don't thing so internal is necessary. It is
> just wrong design.
Depends on how lean you want to be when doing large COPY...right now
the cost is restricted to having to call a function pointer and a few
branches. If
On Tue, 2009-11-24 at 23:44 -0500, Tom Lane wrote:
> If you do that, then there is no possibility of ever using this feature
> except with C-coded functions, which seems to me to remove most of
> whatever use-case there was.
It fits the use case involving dblink (or dblink-like modules).
Maybe th
On Wed, 2009-11-25 at 03:12 +, Greg Stark wrote:
> On Wed, Nov 25, 2009 at 2:10 AM, Tom Lane wrote:
> > As long as there's not anything the master actually does differently
> > then I can't see where there'd be any performance testing to do. What's
> > bothering me about this is that it seems
* It uses dedicated 'SExxx' error codes, but I think they should belong to
the same family of ERRCODE_INSUFFICIENT_PRIVILEGE (42501).
>>> I already uses predefined error code, if exist.
>> What I meant was: there are no problem to add new error codes for SE-PgSQL,
>> but I think the val
On Tue, Nov 24, 2009 at 9:13 PM, Jeff Davis wrote:
>
> I still don't see any reason to force it to be record by record though.
> If the point is to push data from a table into a remote table, why
> should the copied data be translated out of binary format into a record,
> and then back into binar
2009/11/25 Daniel Farina :
> On Tue, Nov 24, 2009 at 8:45 PM, Pavel Stehule
> wrote:
>> It depends on design. I don't thing so internal is necessary. It is
>> just wrong design.
>
> Depends on how lean you want to be when doing large COPY...right now
> the cost is restricted to having to call a f
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
On Tue, Nov 24, 2009 at 9:35 PM, Pavel Stehule wrote:
> 2009/11/25 Daniel Farina :
>> On Tue, Nov 24, 2009 at 8:45 PM, Pavel Stehule
>> wrote:
>>> It depends on design. I don't thing so internal is necessary. It is
>>> just wrong design.
>>
>> Depends on how lean you want to be when doing large
On Wed, Nov 25, 2009 at 3:26 AM, Tom Lane wrote:
> Greg Stark writes:
>> Well the only thing that's been discussed is having vacuum require a
>> minimum age before considering a transaction visible to all to reduce
>> the chance of conflicts on cleanup records.
>
> [ shrug... ] Call me Cassandra
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
2009/11/25 Daniel Farina :
> On Tue, Nov 24, 2009 at 9:35 PM, Pavel Stehule
> wrote:
>> 2009/11/25 Daniel Farina :
>>> On Tue, Nov 24, 2009 at 8:45 PM, Pavel Stehule
>>> wrote:
It depends on design. I don't thing so internal is necessary. It is
just wrong design.
>>>
>>> Depends on ho
On Tue, 2009-11-24 at 21:42 -0800, Daniel Farina wrote:
> You are probably right. We could try coercing to bytea and back out
> to bytes, although it seems like a superfluous cost to force
> *everyone* to pay just to get the same bytes to a network buffer.
Well, I suppose only performance will te
On Wed, 2009-11-25 at 06:35 +0100, Pavel Stehule wrote:
> I believe so using an "internal" minimalize necessary changes in COPY
> implementation. Using a funcapi needs more work inside COPY - you
> have to take some functionality from COPY to stream functions.
> Probably the most slow operations i
1 - 100 of 110 matches
Mail list logo
