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 san
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 heavy
Hannu Krosing ha...@2ndquadrant.com 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.
On Mon, 2009-11-23 at 16:25 -0800, Daniel Farina wrote:
On Mon, Nov 23, 2009 at 4:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
pgsql-hackers had some preliminary discussions a couple months back
on refactoring COPY to allow things like this --- see the thread
starting here:
On Sun, 2009-11-22 at 18:51 -0500, Tom Lane wrote:
Craig Ringer cr...@postnewspapers.com.au 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
On Tue, Nov 24, 2009 at 12:29 AM, Hannu Krosing ha...@krosing.net 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;
On Tue, Nov 24, 2009 at 12:38 AM, Hannu Krosing ha...@2ndquadrant.com 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
2009/11/24 Hannu Krosing ha...@2ndquadrant.com
On Sun, 2009-11-22 at 18:51 -0500, Tom Lane wrote:
Craig Ringer cr...@postnewspapers.com.au 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
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
On Tue, 2009-11-24 at 17:30 +0900, Itagaki Takahiro wrote:
Hannu Krosing ha...@2ndquadrant.com 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
On Tue, Nov 24, 2009 at 2:10 AM, Pavel Stehule pavel.steh...@gmail.com 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 -
On Tue, 2009-11-24 at 02:37 -0800, Daniel Farina wrote:
On Tue, Nov 24, 2009 at 2:10 AM, Pavel Stehule pavel.steh...@gmail.com
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
On Tue, Nov 24, 2009 at 2:50 AM, Hannu Krosing ha...@2ndquadrant.com 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 ]
On Tue, Nov 24, 2009 at 2:51 AM, Daniel Farina drfar...@gmail.com wrote:
On Tue, Nov 24, 2009 at 2:50 AM, Hannu Krosing ha...@2ndquadrant.com wrote:
Can't you use existing aggregate function design ?
CREATE AGGREGATE name ( input_data_type [ , ... ] ) (
SFUNC = sfunc,
STYPE =
On Tue, 2009-11-24 at 09:46 +, Thom Brown wrote:
2009/11/24 Hannu Krosing ha...@2ndquadrant.com
On Sun, 2009-11-22 at 18:51 -0500, Tom Lane wrote:
Craig Ringer cr...@postnewspapers.com.au writes:
I do think this comes up often enough that a built-in
On Tue, 2009-11-24 at 02:56 -0800, Daniel Farina wrote:
On Tue, Nov 24, 2009 at 2:51 AM, Daniel Farina drfar...@gmail.com wrote:
On Tue, Nov 24, 2009 at 2:50 AM, Hannu Krosing ha...@2ndquadrant.com
wrote:
Can't you use existing aggregate function design ?
CREATE AGGREGATE name (
On Tue, Nov 24, 2009 at 3:25 AM, Hannu Krosing ha...@2ndquadrant.com wrote:
On Tue, 2009-11-24 at 02:56 -0800, Daniel Farina wrote:
On Tue, Nov 24, 2009 at 2:51 AM, Daniel Farina drfar...@gmail.com wrote:
On Tue, Nov 24, 2009 at 2:50 AM, Hannu Krosing ha...@2ndquadrant.com
wrote:
Can't
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 mag...@hagander.net wrote:
2009/11/20 Peter Eisentraut pete...@gmx.net:
On fre, 2009-11-20 at 08:39 +0100, Magnus Hagander wrote:
2009/11/20 Peter Eisentraut pete...@gmx.net:
On fre, 2009-11-20 at 02:41 +0100, Magnus Hagander wrote:
Is there
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 regular GiST
2009/11/24 Daniel Farina drfar...@gmail.com:
On Tue, Nov 24, 2009 at 2:10 AM, Pavel Stehule pavel.steh...@gmail.com
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.
On Tue, Nov 24, 2009 at 4:37 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2009/11/24 Daniel Farina drfar...@gmail.com:
On Tue, Nov 24, 2009 at 2:10 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
I thing, so this patch is maybe good idea. I am missing better
function
On Tue, 2009-11-24 at 03:48 -0800, Daniel Farina wrote:
On Tue, Nov 24, 2009 at 3:25 AM, Hannu Krosing ha...@2ndquadrant.com wrote:
On Tue, 2009-11-24 at 02:56 -0800, Daniel Farina wrote:
On Tue, Nov 24, 2009 at 2:51 AM, Daniel Farina drfar...@gmail.com wrote:
On Tue, Nov 24, 2009 at 2:50
2009/11/24 Daniel Farina drfar...@gmail.com:
On Tue, Nov 24, 2009 at 4:37 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2009/11/24 Daniel Farina drfar...@gmail.com:
On Tue, Nov 24, 2009 at 2:10 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
I thing, so this patch is maybe good
On Tue, 2009-11-24 at 05:00 -0800, Daniel Farina wrote:
On Tue, Nov 24, 2009 at 4:37 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
then syntax should be:
COPY table TO streamname(parameters)
COPY table TO filestream('/tmp/foo.dta') ...
COPY table TO
Magnus Hagander mag...@hagander.net 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
On Mon, Nov 23, 2009 at 8:46 PM, Greg Smith g...@2ndquadrant.com 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
2009/11/24 Hannu Krosing ha...@2ndquadrant.com:
On Tue, 2009-11-24 at 05:00 -0800, Daniel Farina wrote:
On Tue, Nov 24, 2009 at 4:37 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
then syntax should be:
COPY table TO streamname(parameters)
COPY table TO filestream('/tmp/foo.dta')
On Mon, Nov 23, 2009 at 9:37 PM, Andrew Dunstan and...@dunslane.net 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.
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
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 section
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 AS SECURITY_CONTEXT natural in English?
We need to put a reserved token, such as AS, prior to the SECURITY_CONTEXT
to avoid
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
Tim Bunce tim.bu...@pobox.com 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
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 and...@dunslane.net 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'
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 Б■┌
Kevin Grittner kevin.gritt...@wicourts.gov 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
Tom Lane t...@sss.pgh.pa.us 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,
Hitoshi Harada umi.tan...@gmail.com 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
Oleg Bartunov o...@sai.msu.su 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.
On Tue, 24 Nov 2009, Tom Lane wrote:
Oleg Bartunov o...@sai.msu.su 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?
On Tue, Nov 24, 2009 at 12:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov 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
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us 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
Oleg Bartunov o...@sai.msu.su 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
On Tue, 24 Nov 2009, Tom Lane wrote:
Oleg Bartunov o...@sai.msu.su 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
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 24, 2009 at 12:28 PM, Tom Lane t...@sss.pgh.pa.us 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
Oleg Bartunov o...@sai.msu.su 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
On tis, 2009-11-24 at 21:32 +0300, Oleg Bartunov wrote:
On Tue, 24 Nov 2009, Tom Lane wrote:
Oleg Bartunov o...@sai.msu.su 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.
On Tue, 24 Nov 2009, Tom Lane wrote:
Oleg Bartunov o...@sai.msu.su 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
On Tue, Nov 24, 2009 at 11:34 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 24, 2009 at 12:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
But actually I thought we had more or less concluded that CREATE OR
REPLACE LANGUAGE would be acceptable (perhaps
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 o...@sai.msu.su 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
Tom Lane t...@sss.pgh.pa.us 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
Oleg Bartunov o...@sai.msu.su 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,
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
Peter Eisentraut pete...@gmx.net 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;
Scott Marlowe scott.marl...@gmail.com writes:
On Tue, Nov 24, 2009 at 11:34 AM, Tom Lane t...@sss.pgh.pa.us 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
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us 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
On Tue, Nov 24, 2009 at 2:07 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Tom Lane t...@sss.pgh.pa.us 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
On Tue, Nov 24, 2009 at 11:57:06AM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com 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
On Tue, 24 Nov 2009, Tom Lane wrote:
Oleg Bartunov o...@sai.msu.su 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
Oleg Bartunov o...@sai.msu.su 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
On Tue, 24 Nov 2009, Tom Lane wrote:
Oleg Bartunov o...@sai.msu.su 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
On Tue, Nov 24, 2009 at 4:49 PM, Oleg Bartunov o...@sai.msu.su wrote:
On Tue, 24 Nov 2009, Tom Lane wrote:
Oleg Bartunov o...@sai.msu.su 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
On Tue, Nov 24, 2009 at 02:19:27PM -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
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 AS SECURITY_CONTEXT natural in English?
We need to put a reserved token, such as AS, prior to the
Roger Leigh rle...@codelibre.net 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
On Tue, Nov 24, 2009 at 05:43:00PM -0500, Tom Lane wrote:
Roger Leigh rle...@codelibre.net 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.
2009/11/25 Tom Lane t...@sss.pgh.pa.us:
Hitoshi Harada umi.tan...@gmail.com 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
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
On Sat, 2009-11-21 at 23:00 +0200, Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
There's no equivalent of XLogArchivingActive()?
XLogArchivingMode() == false enables us to skip WAL-logging in
operations like
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 AS SECURITY_CONTEXT natural in English?
We need to put a reserved token, such as AS,
Simon Riggs si...@2ndquadrant.com 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,
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
WHERE coordinates
Emmanuel Cecchet m...@asterdata.com 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
On Tue, 2009-11-24 at 00:54 -0800, Daniel Farina wrote:
On Tue, Nov 24, 2009 at 12:29 AM, Hannu Krosing ha...@krosing.net 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
KaiGai Kohei kai...@ak.jp.nec.com 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
On Wed, Nov 25, 2009 at 2:10 AM, Tom Lane t...@sss.pgh.pa.us 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
Greg Stark gsst...@mit.edu 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
Itagaki Takahiro wrote:
Emmanuel Cecchet m...@asterdata.com 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
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
Emmanuel Cecchet m...@asterdata.com 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)
(
Itagaki Takahiro wrote:
KaiGai Kohei kai...@ak.jp.nec.com 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
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 pg...@j-davis.com 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
2009/11/25 Jeff Davis pg...@j-davis.com:
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
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
On Tue, Nov 24, 2009 at 8:45 PM, Pavel Stehule pavel.steh...@gmail.com 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
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 the
On Wed, 2009-11-25 at 03:12 +, Greg Stark wrote:
On Wed, Nov 25, 2009 at 2:10 AM, Tom Lane t...@sss.pgh.pa.us 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
* 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 values of the
On Tue, Nov 24, 2009 at 9:13 PM, Jeff Davis pg...@j-davis.com 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
2009/11/25 Daniel Farina drfar...@gmail.com:
On Tue, Nov 24, 2009 at 8:45 PM, Pavel Stehule pavel.steh...@gmail.com
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
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
On Tue, Nov 24, 2009 at 9:35 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2009/11/25 Daniel Farina drfar...@gmail.com:
On Tue, Nov 24, 2009 at 8:45 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
It depends on design. I don't thing so internal is necessary. It is
just wrong design.
On Wed, Nov 25, 2009 at 3:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark gsst...@mit.edu 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.
[
Emmanuel Cecchet m...@asterdata.com 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.
2009/11/25 Daniel Farina drfar...@gmail.com:
On Tue, Nov 24, 2009 at 9:35 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2009/11/25 Daniel Farina drfar...@gmail.com:
On Tue, Nov 24, 2009 at 8:45 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
It depends on design. I don't thing so
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
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 is
1 - 100 of 110 matches
Mail list logo
