decibel wrote:
In this specific case, I think there's enough demand to warrant a
built-in mechanism for granting, but if something like exec() is
built-in then the bar isn't as high for what the built-in GRANT
mechanism needs to handle.
CREATE OR REPLACE FUNCTION tools.exec(
sql text
Fujii Masao wrote:
> On Fri, Aug 7, 2009 at 10:31 AM, Itagaki
> Takahiro wrote:
>> "pg_ctl stop -m smart" will wait for all connections are disconnected and
>> "pg_ctl stop -m fast" will disconnect all connections forcibly.
>> But "fast" after "smart" also wait for disconnections.
>>
>> Can we chan
2009/8/7 Robert Haas :
> On Thu, Aug 6, 2009 at 7:10 PM, Tom Lane wrote:
>> Bernd Helmle writes:
>>> Here again a patch version with updated documentation. I will stop
>>> reviewing this patch now and mark this ready for committer, so we have some
>>> time left to incorporate additional feedback.
On Aug 6, 2009, at 7:12 PM, Robert Haas wrote:
On Thu, Aug 6, 2009 at 7:10 PM, Tom Lane wrote:
Bernd Helmle writes:
Here again a patch version with updated documentation. I will stop
reviewing this patch now and mark this ready for committer, so we
have some
time left to incorporate additi
2009/8/6 Tom Lane :
> Pavel Stehule writes:
>> There is fixed patch. Please, Jaime, can you look on it?
>
> Applied with significant revisions. I really wanted this code factored
> out, because we'd otherwise end up duplicating it in other PLs (and it
> was already duplicative of execQual.c). So
Yes it dramatically decreases the transaction flow.
This function has not been implemented at all for performance but for
analysis purposes.
I used it mainly to have a look at state files size in pg_twophase for
transactions that are prepared but not committed.
Regards
On Fri, Aug 7, 2009 at 12:5
Michael Paquier escribió:
> I also created a page in postgresql's wiki about this feature.
> Please refer to this link:
> http://wiki.postgresql.org/wiki/Pgbench:_shell_command
Please don't use colons in wiki page names. Pgbench_shell_command
should be fine.
--
Alvaro Herrera
Michael Paquier wrote:
> > Here is a short patch implementing a new feature in pgbench so as to allow
> > shell commands to be launched in a transaction file of pgbench.
> > \shell ls ~/pg_twophase;
+1 for \shell command itself, but does the performance fit for your purpose?
Spawning a new proc
On Thu, Aug 6, 2009 at 11:26 PM, Michael
Paquier wrote:
> Sorry I forgot to attach the the patch.
Please add your patches at
https://commitfest.postgresql.org/action/commitfest_view/open
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
2009/8/6 Teodor Sigaev :
>> Isn't that function leaking "res" pointer? Also, I'm curious why you're
>
> fixed
>
>> allocating 2*sizeof(TSLexeme) in unaccent_lexize ...
>
> That's is a dictionary's interface part: lexize returns an array of TSLexeme
> and last structure should have lexeme field NUL
Hi,
On Fri, Aug 7, 2009 at 10:31 AM, Itagaki
Takahiro wrote:
>
> "pg_ctl stop -m smart" will wait for all connections are disconnected and
> "pg_ctl stop -m fast" will disconnect all connections forcibly.
> But "fast" after "smart" also wait for disconnections.
>
> Can we change the behavior that
Sorry I forgot to attach the the patch.
Regards,
Michael
On Fri, Aug 7, 2009 at 12:23 PM, Michael Paquier
wrote:
> Hi all,
>
> Here is a short patch implementing a new feature in pgbench so as to allow
> shell commands to be launched in a transaction file of pgbench.
> the user has just to add
Hi all,
Here is a short patch implementing a new feature in pgbench so as to allow
shell commands to be launched in a transaction file of pgbench.
the user has just to add at the beginning of the command line in his
transaction file \shell + the command wanted.
As an example of transaction:
Begin
On Aug 6, 2009, at 6:00 PM, Bruce Momjian wrote:
Yes, I have regression tests I run but they are not in CVS, partly
because they are tied to other scripts I have to manage server
settings.
Here are my scripts:
http://momjian.us/tmp/pg_migrator_test.tgz
One big problem is that pg_mi
Hi,
I found include/commands/version.h is empty and not included from any files.
What is the purpose of the file?
http://doxygen.postgresql.org/version_8h.html
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Tom Lane wrote:
> Alvaro Herrera writes:
> > Bruce asked me to look for places in the docs that mention that an
> > ANALYZE is recommended, to mention the possibility that autovacuum takes
> > care. This patch does that.
>
> I think you found the right places to touch, but is "let the autovacuum
On Thu, Aug 6, 2009 at 7:10 PM, Tom Lane wrote:
> Bernd Helmle writes:
>> Here again a patch version with updated documentation. I will stop
>> reviewing this patch now and mark this ready for committer, so we have some
>> time left to incorporate additional feedback.
>
> I'm starting to look at t
"pg_ctl stop -m smart" will wait for all connections are disconnected and
"pg_ctl stop -m fast" will disconnect all connections forcibly.
But "fast" after "smart" also wait for disconnections.
Can we change the behavior that "fast" overwrites "smart" mode?
I'd like to achieve the following sequen
On Thu, Aug 6, 2009 at 8:20 PM, Bruce Momjian wrote:
> Josh Berkus wrote:
>> Bruce,
>>
>> > I would love to get out of the release-note-writing business, but I
>> > can't imagine how such a document could be written incrementally, so it
>> > is logical that I would want some kind of test to see tha
Joshua D. Drake wrote:
> On Wed, 2009-08-05 at 22:57 -0400, Bruce Momjian wrote:
> > Andrew Dunstan wrote:
> > >
> > Well, pg_migrator has gotten pretty far without supporting these
> > features, and I think I would have heard about it if someone had these
> > and migrated because vacuum analyze f
David E. Wheeler wrote:
> On Aug 6, 2009, at 7:28 AM, Tom Lane wrote:
>
> > That would cover the problem for OIDs needed during CREATE TABLE, but
> > what about types and enum values?
>
> I haven't been following this discussion very closely, but wanted to
> ask: is someone writing regression t
Peter Eisentraut wrote:
> On Thursday 06 August 2009 06:32:06 Bruce Momjian wrote:
> > I have applied the attached patch to pg_migrator to detect enum,
> > composites, and arrays. I tested it and the only error I got was with
> > the breakmigrator table that was supplied by Jeff, and once I remove
Josh Berkus wrote:
> Bruce,
>
> > I would love to get out of the release-note-writing business, but I
> > can't imagine how such a document could be written incrementally, so it
> > is logical that I would want some kind of test to see that the method I
> > didn't think would work would actually w
Josh Berkus wrote:
> Bruce,
>
> > I would love to get out of the release-note-writing business, but I
> > can't imagine how such a document could be written incrementally, so it
> > is logical that I would want some kind of test to see that the method I
> > didn't think would work would actually w
Bruce,
> I would love to get out of the release-note-writing business, but I
> can't imagine how such a document could be written incrementally, so it
> is logical that I would want some kind of test to see that the method I
> didn't think would work would actually work.
What about Robert's sugge
Robert Haas wrote:
> On Wed, Aug 5, 2009 at 6:59 PM, Josh Berkus wrote:
> >> As far as the release notes, I think we would have to have proof that
> >> the alpha-generated release notes are as good or close to the quality of
> >> the release notes using the current process. ?If they are, we can use
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Is there a reason we don't use pg_type.typcategory to detect arrays in
> > Postgres 8.4? Right now I see this in pg_dump.c:
> >
> > if (g_fout->remoteVersion >= 80300)
> > {
> > appendPQExpBuffer(query, "SELECT tableoid, oid, typname, "
Tom Lane wrote:
> Bruce Momjian writes:
> > Is there a reason we don't use pg_type.typcategory to detect arrays in
> > Postgres 8.4? Right now I see this in pg_dump.c:
>
> typcategory is user-assignable and thus not too reliable; furthermore
> it wouldn't prove that the type is the array type fo
Bruce Momjian wrote:
> Is there a reason we don't use pg_type.typcategory to detect arrays in
> Postgres 8.4? Right now I see this in pg_dump.c:
>
> if (g_fout->remoteVersion >= 80300)
> {
> appendPQExpBuffer(query, "SELECT tableoid, oid, typname, "
> "typnam
Bruce Momjian writes:
> Is there a reason we don't use pg_type.typcategory to detect arrays in
> Postgres 8.4? Right now I see this in pg_dump.c:
typcategory is user-assignable and thus not too reliable; furthermore
it wouldn't prove that the type is the array type for its typelem.
(Consider thi
I'm curious what advantages there are in building compression into
the database itself, rather than using filesystem-based compression.
I see ZFS articles[1] discuss how enabling compression
improves performance with ZFS; for Linux, Btrfs has compression
features as well[2]; and on Windows NTFS se
Bernd Helmle writes:
> Here again a patch version with updated documentation. I will stop
> reviewing this patch now and mark this ready for committer, so we have some
> time left to incorporate additional feedback.
I'm starting to look at this now, and my very first reaction was
"what in the w
Is there a reason we don't use pg_type.typcategory to detect arrays in
Postgres 8.4? Right now I see this in pg_dump.c:
if (g_fout->remoteVersion >= 80300)
{
appendPQExpBuffer(query, "SELECT tableoid, oid, typname, "
"typnamespace, "
On 8/6/09 1:03 PM, Greg Stark wrote:
> One possibility is to handle only read-only tables. That would make
> things a *lot* simpler. But it sure would be inconvenient if it's only
> useful on large static tables but requires you to rewrite the whole
> table -- just what you don't want to do with la
Zdenek Kotala writes:
> It seems to me that editline never distributed history.h file and
> HAVE_EDITLINE_HISTORY_H is nonsense. But I'm not sure.
I wouldn't count on that, in part because there are so many versions of
editline. On an OS X machine I see
$ ls -l /usr/include/*line*
/usr/include/
Greg Stark wrote:
> 2009/8/6 Alvaro Herrera :
> >> 2009-08-05 11:58:19 COTLOG: la dirección de página 0/6D374000 en el
> >> archivo de registro 0, segmento 117, posición 3620864 es inesperada
> >
>
> Incidentally, Google's translate gives me the impression that the
> above message corresponds to:
Greg Stark writes:
> 2009/8/6 Alvaro Herrera :
> 2009-08-05 11:58:19 COTLOG: la dirección de página 0/6D374000 en el
> archivo de registro 0, segmento 117, posición 3620864 es inesperada
>>
> Incidentally, Google's translate gives me the impression that the
> above message corresponds to:
>
2009/8/6 Alvaro Herrera :
>> 2009-08-05 11:58:19 COTLOG: la dirección de página 0/6D374000 en el
>> archivo de registro 0, segmento 117, posición 3620864 es inesperada
>
Incidentally, Google's translate gives me the impression that the
above message corresponds to:
if (!XLByteEQ(hdr->xlp
Greg Stark wrote:
> 2009/8/6 Alvaro Herrera :
> > After adding %p to the log_line_prefix, it becomes clear that the
> > process calling XLogInsert here is the startup process.
> >
> > This is new code in 8.4. Is no one concerned about this?
>
> Can you get a backtrace?
I'll ask the user.
--
Al
2009/8/6 Alvaro Herrera :
> After adding %p to the log_line_prefix, it becomes clear that the
> process calling XLogInsert here is the startup process.
>
> This is new code in 8.4. Is no one concerned about this?
Can you get a backtrace?
--
greg
http://mit.edu/~gsstark/resume.pdf
--
Sent via
Alvaro Herrera writes:
> This is new code in 8.4. Is no one concerned about this?
[ shrug... ] It's uninvestigatable with only this amount of detail.
How about a test case, or at least a backtrace?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hacker
Pavel Stehule writes:
> There is fixed patch. Please, Jaime, can you look on it?
Applied with significant revisions. I really wanted this code factored
out, because we'd otherwise end up duplicating it in other PLs (and it
was already duplicative of execQual.c). So I pushed the support code
int
Robert Haas wrote:
> On Thu, Aug 6, 2009 at 4:03 PM, Greg Stark wrote:
>> I like the idea too, but I think there are some major problems to
>> solve. In particular I think we need a better solution to blocks
>> growing than sparse files.
>
> How much benefit does this approach have over using TO
When I try compile postgresql with --libeditpreferred option,
compilation fails when readline is also installed on the system. You can
see error report on:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dot_moth&dt=2009-08-06%2012:46:04
The main problem is in src/bin/psql/input.h where is foll
Alvaro Herrera wrote:
> 2009-08-05 11:58:19 COTLOG: el sistema de bases de datos fue
> interrumpido durante la recuperación en 2009-08-05 11:12:14 COT
> 2009-08-05 11:58:19 COTHINT: Esto probablemente significa que
> algunos datos están corruptos y tendrá que usar el respaldo más
> reciente para
Hi,
I've been looking through the current state of docuemtation,
including comments, with respect to the executor code and I would
like to improve upon their condition. If anyone has notes,
pseudocode, thoughts on how it all really works, or anything that
ca
On Thu, Aug 6, 2009 at 4:03 PM, Greg Stark wrote:
> I like the idea too, but I think there are some major problems to
> solve. In particular I think we need a better solution to blocks
> growing than sparse files.
How much benefit does this approach have over using TOAST compression
more aggressiv
I like the idea too, but I think there are some major problems to
solve. In particular I think we need a better solution to blocks
growing than sparse files.
The main problem with using sparse files is that currently postgres is
careful to allocate blocks early so it can fail if there's not enoug
Pierre,
On Thu, Aug 6, 2009 at 11:39 AM, PFC wrote:
> The best for this is lzo : very fast decompression, a good compression ratio
> on a sample of postgres table and indexes, and a license that could work.
The license of lzo doesn't allow us to include it in PostgreSQL
without relicensing Postgr
On 8/6/09 2:39 AM, PFC wrote:
>
>
> With the talk about adding compression to pg_dump lately, I've been
> wondering if tables and indexes could be compressed too.
> So I've implemented a quick on-the-fly compression patch for postgres
I find this very interesting, and would like to test it f
>
> \cmd grant select on * to user
>
when I wrote epsql I implemented \fetchall metastatement.
http://okbob.blogspot.com/2009/03/experimental-psql.html
It's should be used for GRANT
DECLARE x CURSOR FOR SELECT * FROM information_schema.tables
\fetchall x GRANT ALL ON :table_name TO public;
On Aug 5, 2009, at 11:59 AM, Tom Lane wrote:
Robert Haas writes:
... bulk-grant could be based on object type,
object name (with wildcard or regexp pattern), schema membership, or
maybe other things, and I think that would be quite useful if we can
figure out how to make it clean and elegant.
Peter Eisentraut writes:
> And then, what is the supposed semantics of calling a nonstrict input
> function with NULL as the cstring value? InputFunctionCall() requires
> that the return value is null if and only if the input cstring was
> NULL, "but we'll call the input function anyway". Couldn
"Kevin Grittner" wrote:
> From what I could find on a quick scan:
>
> RETURNED_SQLSTATE
> CLASS_ORIGIN
> SUBCLASS_ORIGIN
> CONSTRAINT_CATALOG
> CONSTRAINT_SCHEMA
> CONSTRAINT_NAME
> CATALOG_NAME
> SCHEMA_NAME
> TABLE_NAME
> COLUMN_NAME
> CURSOR_NAME
> MESSAGE_TEXT
> MESSAGE_LENGTH
> MESSAGE_OCT
On Thu, Aug 6, 2009 at 11:32, Todd A. Cook wrote:
> Tom Lane wrote:
>>
>> I took a look through the CVS history and verified that there were
>> no post-8.4 commits that looked like they'd affect performance in
>> this area. So I think it's got to be a platform difference not a
>> PG version differ
On Thu, Aug 6, 2009 at 12:53 PM, Jeff Davis wrote:
> On Thu, 2009-08-06 at 12:19 -0400, Robert Haas wrote:
>> Based on these comments, do you want to go ahead and mark this "Ready
>> for Committer"?
>
> Done, thanks Teodor.
>
> However, on the commitfest page, the patches got updated in the wrong
>
Tom Lane wrote:
The attached prototype patch does this
and seems to fix the speed problem nicely. It's not tremendously
well tested, but perhaps you'd like to test? Should work in 8.4.
I'll give it a try and report back (though probably not until tomorrow).
-- todd
--
Sent via pgsql-hacker
Tom Lane wrote:
I took a look through the CVS history and verified that there were
no post-8.4 commits that looked like they'd affect performance in
this area. So I think it's got to be a platform difference not a
PG version difference. In particular I think we are probably looking
at a filesy
Tom Lane wrote:
> I'm not proposing that we implement GET DIAGNOSTICS as a statement.
> I was just thinking that the list of values it's supposed to make
> available might do as a guide to what extra error fields we need to
> provide where.
>From what I could find on a quick scan:
RETURNED_S
On Thursday 06 August 2009 17:33:40 Tom Lane wrote:
> I don't think there'd be much logical difficulty in having an output
> field (ie, CSV column or log_line_prefix escape) that represents a
> classification of the PID, say as "postmaster, backend, AV worker,
> AV launcher, bgwriter, ...". It wou
I'm reviewing the plpython data type handling patch from the commit fest. I
have not dealt much with the plpython code before, and I'm a bit puzzled by
its elaborately silly handling of null values. A representative example (for
the current code):
if (tupdesc->attrs[at
On Thu, 2009-08-06 at 12:19 -0400, Robert Haas wrote:
> Based on these comments, do you want to go ahead and mark this "Ready
> for Committer"?
Done, thanks Teodor.
However, on the commitfest page, the patches got updated in the wrong
places: "prefix support" and "filtering dictionary support" ar
Today we got a report in the spanish list about the message in $subject.
The server is 8.4 running on Windows.
Any ideas? I'm wondering what kind of diagnostics we can run to debug
the problem. xlogdump perhaps?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
Pos
On Thu, Aug 6, 2009 at 11:11 AM, Andrew Dunstan wrote:
>
> Last night I needed to move a bunch of data from an OLTP database to an
> archive database, and used dblink with a bunch of insert statements. Since I
> was moving about 4m records this was distressingly but not surprisingly
> slow. It set
On Thu, Aug 06, 2009 at 12:28:15PM -0400, Andrew Dunstan wrote:
> David Fetter wrote:
>>
>> For what it's worth, DBI-Link provides a lot of this.
>
> Indeed, but that assumes that perl+DBI+DBD::Pg is available, which
> is by no means always the case. If we're going to have a dblink
> module ISTM i
On Thu, Aug 06, 2009 at 11:41:55AM +0200, Pavel Stehule wrote:
> typically in SQL/PSM (stored procedures - look on GET DIAGNOSTICS
> statement in plpgsql doc), maybe in ecpg. Other's environments raise
> exception - so you can get some data from exception or from special
> structures related to env
David Fetter wrote:
For what it's worth, DBI-Link provides a lot of this.
Indeed, but that assumes that perl+DBI+DBD::Pg is available, which is by
no means always the case. If we're going to have a dblink module ISTM it
should be capable of reasonable bulk operations.
cheers
andrew
2009/8/6 Teodor Sigaev :
>> 1. The docs should be clarified a little. For instance, it should have a
>> link back to the definition of a prefix search (12.3.2). I included my
>> doc suggestions as an attachment.
>
> Thank you, merged
>
>> 2. dsynonym_init() uses findwrd() in a slightly confusing (a
1. The docs should be clarified a little. For instance, it should have a
link back to the definition of a prefix search (12.3.2). I included my
doc suggestions as an attachment.
Thank you, merged
2. dsynonym_init() uses findwrd() in a slightly confusing (and perhaps
fragile) way. After calling
On Thu, Aug 06, 2009 at 11:11:58AM -0400, Andrew Dunstan wrote:
>
> Last night I needed to move a bunch of data from an OLTP database to an
> archive database, and used dblink with a bunch of insert statements.
> Since I was moving about 4m records this was distressingly but not
> surprisingl
On Wed, 2009-08-05 at 22:57 -0400, Bruce Momjian wrote:
> Andrew Dunstan wrote:
> >
> Well, pg_migrator has gotten pretty far without supporting these
> features, and I think I would have heard about it if someone had these
> and migrated because vacuum analyze found it right away. I am afraid
>
On Thu, Aug 6, 2009 at 11:11 AM, Andrew Dunstan wrote:
>
> Last night I needed to move a bunch of data from an OLTP database to an
> archive database, and used dblink with a bunch of insert statements. Since I
> was moving about 4m records this was distressingly but not surprisingly
> slow. It set
* Andrew Dunstan (and...@dunslane.net) wrote:
> Tom Lane wrote:
>> I'm not sure whether there is consensus on not using GRANT ON VIEW
>> (ie, having these patches treat tables and views alike). I was waiting
>> to see if Stephen would put forward a convincing counterargument ...
>
> Conceptually i
Last night I needed to move a bunch of data from an OLTP database to an
archive database, and used dblink with a bunch of insert statements.
Since I was moving about 4m records this was distressingly but not
surprisingly slow. It set me wondering why we don't build more support
for libpq oper
On Thursday 06 August 2009 17:54:37 David E. Wheeler wrote:
> On Aug 6, 2009, at 7:28 AM, Tom Lane wrote:
> > That would cover the problem for OIDs needed during CREATE TABLE, but
> > what about types and enum values?
>
> I haven't been following this discussion very closely, but wanted to
> ask: i
On Aug 6, 2009, at 7:28 AM, Tom Lane wrote:
That would cover the problem for OIDs needed during CREATE TABLE, but
what about types and enum values?
I haven't been following this discussion very closely, but wanted to
ask: is someone writing regression tests for these cases that
pg_migrator
Magnus Hagander writes:
> On Thu, Aug 6, 2009 at 16:33, Tom Lane wrote:
>> I don't think there'd be much logical difficulty in having an output
>> field (ie, CSV column or log_line_prefix escape) that represents a
>> classification of the PID, say as "postmaster, backend, AV worker,
>> AV launcher
On Thu, Aug 6, 2009 at 4:32 AM, Dimitri Fontaine wrote:
> Tom Lane writes:
>
>> Andrew Dunstan writes:
>>> preventing a clash might be fairly difficult.
>>
>> Yeah, I was just thinking about that. The easiest way to avoid
>> collisions would be to make pg_dump (in --binary-upgrade mode)
>> respo
Andrew Dunstan writes:
> It's going to be fairly grotty whatever we do. I'm worried a bit that
> we'll be providing some footguns, but I guess we'll just need to hold
> our noses and do whatever it takes.
Yeah. One advantage of the GUC approach is we could make 'em SUSET.
I don't actually see
On Thu, Aug 6, 2009 at 16:33, Tom Lane wrote:
> Magnus Hagander writes:
>> On Thu, Aug 6, 2009 at 16:20, Tom Lane wrote:
>>> Well, it seems like you could get 90% of the way there just by filtering
>>> on the PID --- watching the bgwriter, walwriter, and archiver should
>>> cover this use-case rea
Tom Lane wrote:
Alvaro Herrera writes:
Dimitri Fontaine wrote:
It seems harder to come up with a general purpose syntax to support the
feature in case of toast tables, though.
There's already general purpose syntax for relation options which can be
used to get options th
Andrew Dunstan writes:
> Kevin Grittner wrote:
>> Any idea whether domains are an issue?
> I don't believe that they are an issue. The issue arises only when a
> catalog oid is used in the on-disk representation of a type. AFAIK the
> on-disk representation of a domain is the same as its base t
Magnus Hagander writes:
> On Thu, Aug 6, 2009 at 16:20, Tom Lane wrote:
>> Well, it seems like you could get 90% of the way there just by filtering
>> on the PID --- watching the bgwriter, walwriter, and archiver should
>> cover this use-case reasonably well.
> Right. But that's pretty hard to do
Kevin Grittner wrote:
Andrew Dunstan wrote:
Excluding every database that has a composite/array-of
user-defined-type/enum type would be pretty nasty. After all, these
are features we boast of.
Any idea whether domains are an issue? I was thinking of trying this
tool soon, and w
Alvaro Herrera writes:
> Dimitri Fontaine wrote:
>> It seems harder to come up with a general purpose syntax to support the
>> feature in case of toast tables, though.
> There's already general purpose syntax for relation options which can be
> used to get options that do not ultimately end up in
Isn't that function leaking "res" pointer? Also, I'm curious why you're
fixed
allocating 2*sizeof(TSLexeme) in unaccent_lexize ...
That's is a dictionary's interface part: lexize returns an array of TSLexeme and
last structure should have lexeme field NULL.
filter_dictionary file is not ch
On Thu, Aug 6, 2009 at 16:20, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Aug 5, 2009 at 16:11, Heikki
>> Linnakangas wrote:
>>> Would you like to propose a concrete list sources that we would have?
>>> The implementation effort depends a lot on the categorization.
>
>> Well, the only one
Magnus Hagander writes:
> On Wed, Aug 5, 2009 at 16:11, Heikki
> Linnakangas wrote:
>> Would you like to propose a concrete list sources that we would have?
>> The implementation effort depends a lot on the categorization.
> Well, the only one I have a direct usecase for is the one that is "I
> w
Andrew Dunstan wrote:
> Excluding every database that has a composite/array-of
> user-defined-type/enum type would be pretty nasty. After all, these
> are features we boast of.
Any idea whether domains are an issue? I was thinking of trying this
tool soon, and we don't seem to be using any o
>
>
> What use is there for fuzzy predicates? I think it would mainly be to
> stop more students from coming up with new implementations of the same
> thing over and over.
>
Well, I'm sorry if anyone of us who is involved on these projects have
already explain the true usefulness of sqlf and fuzz
Dimitri Fontaine wrote:
> Tom Lane writes:
> > We could stop doing that
> > once we have all the user tables in place --- I don't believe it's
> > necessary to preserve the OIDs of user indexes. But we need to
> > preserve toast table OIDs, and toast table index OIDs too if those
> > are created
On Wed, Aug 5, 2009 at 16:11, Heikki
Linnakangas wrote:
> Magnus Hagander wrote:
>> As for the source, I think we'd just "decorate" the error messages
>> with errsource(ERRSOURCE_USER) or something like that at places where
>> needed, and have it default to "internal" - so we don't have to touch
>>
On Wed, Aug 5, 2009 at 16:53, Tom Lane wrote:
> Magnus Hagander writes:
But. I'll look into cleaning those up for HEAD anyway, but due to lack
of reports I think we should skip backpatch. Reasonable?
>>>
>>> Fair enough.
>
>> Here's what I came up with. Seems ok?
>
> Works for me.
Appli
On Wednesday 05 August 2009 17:45:46 Pavel Stehule wrote:
> SQLCODE could carry enough information about user or system exception.
> There are reserved space for custom codes. Maybe for administration
> should be interesting, if error is system error or application error -
> but this should be desc
On Wednesday 05 August 2009 16:13:48 Magnus Hagander wrote:
> Just to verify, there is not going to be any changes in the actual
> format of the generated files, right?
Correct.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
On Thursday 06 August 2009 06:32:06 Bruce Momjian wrote:
> I have applied the attached patch to pg_migrator to detect enum,
> composites, and arrays. I tested it and the only error I got was with
> the breakmigrator table that was supplied by Jeff, and once I removed
> that table the migration wen
2009/8/6 Sam Mason :
> On Wed, Aug 05, 2009 at 08:57:14PM +0200, Pavel Stehule wrote:
>> 2009/8/5 Tom Lane :
>> > Peter pointed out upthread that the SQL standard already calls out some
>> > things that should be available in this way --- has anyone studied that
>> > yet?
>>
>> yes - it's part of G
With the talk about adding compression to pg_dump lately, I've been
wondering if tables and indexes could be compressed too.
So I've implemented a quick on-the-fly compression patch for postgres
Sorry for the long email, but I hope you find this interesting.
Why compress ?
1- To sa
On Wed, Aug 05, 2009 at 08:57:14PM +0200, Pavel Stehule wrote:
> 2009/8/5 Tom Lane :
> > Peter pointed out upthread that the SQL standard already calls out some
> > things that should be available in this way --- has anyone studied that
> > yet?
>
> yes - it's part of GET DIAGNOSTICS statement
>
Tom Lane írta:
> At the moment it looks to me like pg_migrator has crashed and burned
> for 8.4, at least for general-purpose usage.
It means that you don't have the restraint that
you thought you have. So you can change the
RedHat/Fedora PostgreSQL 8.4 packages to use
the upstream default for int
1 - 100 of 103 matches
Mail list logo
