Le 24/01/2010 06:06, Jaime Casanova a écrit :
On Sat, Jan 23, 2010 at 10:08 PM, Robert Haas robertmh...@gmail.com wrote:
I was also thinking about the possibility of adding a new option
called output and making that control whether the Output line gets
printed. It's kind of annoying to use
2010/1/22 Robert Haas robertmh...@gmail.com:
On Fri, Jan 22, 2010 at 7:19 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
here is new variant. Add scan_state flag valid and enhance
protection against execution broken statement.
This doesn't make sense to me. You've changed the way \set is
Hello
2010/1/22 David E. Wheeler da...@kineticode.com:
Pavel,
My review of your listagg patch.
Submission Review
-
* The diff is a context diff and applies cleanly to HEAD (with just two hunks
offset by 2 lines each).
* There is documentation, though I'm not sure it
(2010/01/24 12:40), KaiGai Kohei wrote:
Perhaps, it may be a good idea to make two conceptual patches both head of
the ATPrepCmd() and ATExec*(). They will make clear good/bad points between
two approaches.
I tried to make two conceptual patches.
* pgsql-at-rework-prep.1.patch
It adds
isn't that line pretty much the main point of verbose? I would assume
anything new like this would get its own option which might default to on.
greg
On 24 Jan 2010 03:08, Robert Haas robertmh...@gmail.com wrote:
Per recent discussion on pgsql-performance, and per discussion on
-hackers that it
--On 23. Januar 2010 22:29:23 -0500 Robert Haas robertmh...@gmail.com
wrote:
I don't think this is ready for committer, becauseTom previously
objected to the approach taken by this patch here, and no one has
answered his objections:
On Sun, Jan 24, 2010 at 12:06 AM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
On Sat, Jan 23, 2010 at 10:08 PM, Robert Haas robertmh...@gmail.com wrote:
I was also thinking about the possibility of adding a new option
called output and making that control whether the Output line gets
On Sat, Jan 23, 2010 at 10:48 PM, KaiGai Kohei kai...@kaigai.gr.jp wrote:
(2010/01/24 12:29), Robert Haas wrote:
I don't think this is ready for committer, becauseTom previously
objected to the approach taken by this patch here, and no one has
answered his objections:
On Sun, Jan 24, 2010 at 8:36 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Jan 23, 2010 at 10:48 PM, KaiGai Kohei kai...@kaigai.gr.jp wrote:
(2010/01/24 12:29), Robert Haas wrote:
I don't think this is ready for committer, becauseTom previously
objected to the approach taken by this
On Fri, Jan 22, 2010 at 06:11:51PM +0100, Boszormenyi Zoltan wrote:
Why does the preproc spit out ECPGset_var's but no ECPGget_var's in this
test case?
Because there's no ECPGget_var()s emitted for
- global variables
- variables in the same function
ECPGget_var() is only used in
2010/1/20 KaiGai Kohei kai...@ak.jp.nec.com:
(2010/01/20 0:19), Magnus Hagander wrote:
* I think this comment is right.
+ for (i = 0; i RADIUS_VECTOR_LENGTH; i++)
+ /* XXX: Generate a more secure random string? */
+ packet-vector[i] = random() % 255;
The random seed
1. I think rb_free_recursive is missing a pfree().
Fixed, thank you
2. We already have a definition of NIL in the PG source base. I think
this one needs to be named something else. RBNIL, maybe.
fixed
3. This code could really use some more comments, and maybe some of
the variable names
2009/1/22 Informatica-Cooperativa Cnel. Oviedo informat...@coopovie.com.py:
Buenos Dias todos,
Soy un usuario de postgres de Paraguay, consulto
sobre la posibilidad de inclucion en la futura version la siguiente
sentencia(Uso de alias en la condicion HAVING ):
Andrew Dunstan wrote:
Perhaps it isn't that five months is outrageous, but that it
doesn't really benefit from an unorganized swarm of activity by
all the developers, and we've not worked out a reasonable
framework for who should do what during that time to best benefit
the project while
2010/1/24 Teodor Sigaev teo...@sigaev.ru:
3. This code could really use some more comments, and maybe some of
the variable names could be better chosen, too. It's far from obvious
what is going on here. I studied rbtrees in college and I still
remember more or less how they work, but, boy,
Greg Smith wrote:
Developing new features is fun and tends to attract sponsorship
dollars. Testing a frozen release, finding bugs, and resolving them
is boring, and no one sponsors it. Therefore, if you let both
things go on at once, I guarantee you almost all of the community
attention
Would it be OK if I went through here and hacked on the comments and
sent this back to you?
Feel free to edit the patch.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via
2010/1/24 Magnus Hagander mag...@hagander.net:
2010/1/20 KaiGai Kohei kai...@ak.jp.nec.com:
As Tom pointed out, it is fundamentally same.
The matter is this random() invocation is the first time after
initialization of random seed by srandom(). It means an external observer
can estimate the
On lör, 2010-01-23 at 18:00 -0700, Brook Milligan wrote:
It seems that src/Makefile.shlib has special cases for several
directories that build loadable modules rather than shared libraries.
The contrib/adminpack is one of the special cases, but none of the
other contrib directories are. As a
Kevin Grittner wrote:
Greg Smith wrote:
Developing new features is fun and tends to attract sponsorship
dollars. Testing a frozen release, finding bugs, and resolving them
is boring, and no one sponsors it. Therefore, if you let both
things go on at once, I guarantee you almost all of
In the spirit of finishing off small patches, attached is the one that
implements pg_stat_reset_single(), to be able to reset stats for a
single table or function. I kind of thought it would be included in
the patch from Greg Smith for shared counters so I put it aside, but I
guess I misunderstood
On Jan 24, 2010, at 1:19 AM, Pavel Stehule wrote:
can I help with it, please. My English is terrible.
Yes, I added a bit in the patch I submitted.
array user functions are used more time in pg core. The complexity of
array functions are much higher, so I don't think we need special
file.
Magnus Hagander mag...@hagander.net writes:
In the spirit of finishing off small patches, attached is the one that
implements pg_stat_reset_single(), to be able to reset stats for a
single table or function. I kind of thought it would be included in
the patch from Greg Smith for shared
Robert Haas robertmh...@gmail.com writes:
2009/1/22 Informatica-Cooperativa Cnel. Oviedo informat...@coopovie.com.py:
SELECT id, sum(salario) as SumaSalario
FROM salarios
GROUP BY id
HAVING SumaSalario500;
I've wished for that syntax once or twice myself, but I'm assuming
Kevin Grittner wrote:
You've as much as said that it's a given that many of the
contributors will continue to work on new patches during this period
to earn a living, while hopefully volunteering to help with getting
the release out the door on their own time. As I understand the
arguments,
2010/1/24 Tom Lane t...@sss.pgh.pa.us:
Magnus Hagander mag...@hagander.net writes:
In the spirit of finishing off small patches, attached is the one that
implements pg_stat_reset_single(), to be able to reset stats for a
single table or function. I kind of thought it would be included in
the
Peter Eisentraut wrote:
On lör, 2010-01-23 at 12:42 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Was there a designed-in reason not to have psql tab completion for
COMMIT/ROLLBACK PREPARED ...? It does complete the PREPARED but not
the transaction identifiers. Maybe it's
Robert Haas robertmh...@gmail.com writes:
On Sun, Jan 24, 2010 at 12:06 AM, Jaime Casanova
why not let it go in ANALYZE, just as the sort info
It's kinda long-winded - it adds like 4 extra lines for each hash
join. I don't think I want to add that much clutter to regular E-A
output.
Well,
Heikki Linnakangas wrote:
Peter Eisentraut wrote:
On l?r, 2010-01-23 at 12:42 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Was there a designed-in reason not to have psql tab completion for
COMMIT/ROLLBACK PREPARED ...? It does complete the PREPARED but not
the
Tom Lane t...@sss.pgh.pa.us wrote:
I'm not so worried about the amount of RAM needed as whether
pg_dump's internal algorithms will scale to large numbers of TOC
entries. Any O(N^2) behavior would be pretty painful, for
example. No doubt we could fix any such problems, but it might
take
On Sun, 2010-01-24 at 18:25 +0100, Magnus Hagander wrote:
2010/1/24 Tom Lane t...@sss.pgh.pa.us:
Magnus Hagander mag...@hagander.net writes:
In the spirit of finishing off small patches, attached is the one that
implements pg_stat_reset_single(), to be able to reset stats for a
single
Andrew Dunstan and...@dunslane.net wrote:
As for getting more coverage of Beta, part of my trouble in
testing applications on Beta is that there aren't good tools I
know of for capture and replay of usage scenarios. Now there would
be a good project for someone, and it would be unaffected by
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Right, I vaguely recall that the idea of tab-completion for those
commands was rejected when 2PC was added because of that. A user sitting
at a psql terminal is not supposed to prepare a transaction. That's
application server's business.
I
Heikki Linnakangas wrote:
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Right, I vaguely recall that the idea of tab-completion for those
commands was rejected when 2PC was added because of that. A user sitting
at a psql terminal is not supposed to prepare a transaction. That's
2010/1/24 Magnus Hagander mag...@hagander.net:
2010/1/24 Tom Lane t...@sss.pgh.pa.us:
Magnus Hagander mag...@hagander.net writes:
In the spirit of finishing off small patches, attached is the one that
implements pg_stat_reset_single(), to be able to reset stats for a
single table or function.
On Sun, 2010-01-24 at 19:29 +0200, Heikki Linnakangas wrote:
Peter Eisentraut wrote:
On lör, 2010-01-23 at 12:42 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Was there a designed-in reason not to have psql tab completion for
COMMIT/ROLLBACK PREPARED ...? It does
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Peter Eisentraut wrote:
The scenario that I encountered is that you go around manually cleaning
them up when the XA software fails for some reason.
Hmm, that's a good point though. Maybe it would make sense to add tab
completion
Kevin Grittner kevin.gritt...@wicourts.gov writes:
I'm afraid pg_dump didn't get very far with this before:
pg_dump: WARNING: out of shared memory
pg_dump: SQL command failed
Given how fast it happened, I suspect that it was 2672 tables into
the dump, versus 26% of the way through 5.5
Simon Riggs si...@2ndquadrant.com writes:
I would like a mechanism in the server to prevent a session from
accepting anything other than COMMIT or ROLLBACK PREPARED after a
PREPARE. Otherwise it's possible to screw up your prepared xact and
leave it hanging there.
Uh, what? That makes no
Tom Lane t...@sss.pgh.pa.us wrote:
It might be better to try a test case with lighter-weight objects,
say 5 million simple functions.
So the current database is expendable? I'd just as soon delete it
before creating the other one, if you're fairly confident the other
one will do it.
On Fri, 2010-01-22 at 11:14 -0800, David E.Wheeler wrote:
No performance issues
ISTM that this class of function is inherently dangerous performance
wise.
* It looks incredibly easy to construct enormous lists. We should test
the explosion limit of this to see how it is handled. Perhaps we
Magnus Hagander mag...@hagander.net writes:
Here goes.
Looks much saner. One minor stylistic gripe:
+Datum
+pg_stat_reset_single_table(PG_FUNCTION_ARGS)
+{
+ pgstat_reset_single_counter(PG_GETARG_OID(0), RESET_TABLE);
+
+ PG_RETURN_VOID();
+}
I don't like sticking PG_GETARG calls
Magnus Hagander escreveu:
Off to make it two separate functions.. (seems much more user-friendly
than a single function with an extra argument, IMHO)
+1. But as Simon said _single_ is too ugly. What about
pg_stat_reset_user_{function,relation}?
Another thing that is not a problem of your
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
It might be better to try a test case with lighter-weight objects,
say 5 million simple functions.
So the current database is expendable?
Yeah, I think it was a bad experimental design anyway...
--On 24. Januar 2010 08:37:13 -0500 Robert Haas robertmh...@gmail.com
wrote:
I agree - the requirements here are much looser than for, say, SELECT
or UPDATE. But it still has to not suck.
Yeah, i think the meaning of suck can be much weakier than for a DML
command. However, if it would
Euler Taveira de Oliveira eu...@timbira.com writes:
Magnus Hagander escreveu:
Off to make it two separate functions.. (seems much more user-friendly
than a single function with an extra argument, IMHO)
+1. But as Simon said _single_ is too ugly. What about
On Sun, 2010-01-24 at 12:54 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
I would like a mechanism in the server to prevent a session from
accepting anything other than COMMIT or ROLLBACK PREPARED after a
PREPARE. Otherwise it's possible to screw up your prepared xact and
Kevin Grittner wrote:
Andrew Dunstan and...@dunslane.net wrote:
As for getting more coverage of Beta, part of my trouble in
testing applications on Beta is that there aren't good tools I
know of for capture and replay of usage scenarios. Now there would
be a good project for someone, and
2010/1/24 Tom Lane t...@sss.pgh.pa.us:
Euler Taveira de Oliveira eu...@timbira.com writes:
Magnus Hagander escreveu:
Off to make it two separate functions.. (seems much more user-friendly
than a single function with an extra argument, IMHO)
+1. But as Simon said _single_ is too ugly. What
Bernd Helmle maili...@oopsware.de writes:
--On 24. Januar 2010 08:37:13 -0500 Robert Haas robertmh...@gmail.com
wrote:
I think the problem case here might be something like this...
Did that with a crude pl/pgsql script, and got the following numbers:
I think my concern about the original
Michael Meskes írta:
On Fri, Jan 22, 2010 at 06:11:51PM +0100, Boszormenyi Zoltan wrote:
Why does the preproc spit out ECPGset_var's but no ECPGget_var's in this
test case?
Because there's no ECPGget_var()s emitted for
- global variables
- variables in the same function
Magnus Hagander mag...@hagander.net writes:
2010/1/24 Tom Lane t...@sss.pgh.pa.us:
The pg_stat_ prefix is some help but not enough IMO. So I suggest
pg_stat_reset_table_counters and pg_stat_reset_function_counters.
Doesn't the pg_stat_ part already say this?
My objection is that reset_table
2010/1/24 Simon Riggs si...@2ndquadrant.com:
On Fri, 2010-01-22 at 11:14 -0800, David E.Wheeler wrote:
No performance issues
ISTM that this class of function is inherently dangerous performance
wise.
there is potencial risk, but this risk isn't new. The almost all what
you say is true for
2010/1/24 Tom Lane t...@sss.pgh.pa.us:
Magnus Hagander mag...@hagander.net writes:
2010/1/24 Tom Lane t...@sss.pgh.pa.us:
The pg_stat_ prefix is some help but not enough IMO. So I suggest
pg_stat_reset_table_counters and pg_stat_reset_function_counters.
Doesn't the pg_stat_ part already say
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2010-01-22 at 11:14 -0800, David E.Wheeler wrote:
No performance issues
ISTM that this class of function is inherently dangerous performance
wise.
* It looks incredibly easy to construct enormous lists. We should test
the explosion limit
2010/1/24 David E. Wheeler da...@kineticode.com:
On Jan 24, 2010, at 1:19 AM, Pavel Stehule wrote:
can I help with it, please. My English is terrible.
Yes, I added a bit in the patch I submitted.
array user functions are used more time in pg core. The complexity of
array functions are much
--On 24. Januar 2010 13:23:14 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
I think my concern about the original proposal was that the time to
perform an ALTER RENAME would increase with the number of tables in the
database, even if they were entirely unrelated to the one you're trying
to rename.
Tom Lane escreveu:
That implies that the operations wouldn't work against system tables;
which they do. I think a bigger problem is that reset_single_table
seems like it might be talking about something like a TRUNCATE, ie,
it's not clear that it means to reset counters rather than data.
The
--On 24. Januar 2010 19:45:33 +0100 Bernd Helmle maili...@oopsware.de
wrote:
I don't see where this should be related to the number of tables not
part of the inheritance tree (or inheritance at all).
To answer that myself: it seems get_attname() introduces the overhead here
(forgot
On Saturday 23 January 2010 16:19:11 Andrew Dunstan wrote:
Robert Treat wrote:
I'm not saying there aren't
downsides, but having a name the community can unify on is a definite
plus, and imho that name has to be Postgres.
Translation: we'll only be unified if everyone agrees with me.
2010/1/24 Euler Taveira de Oliveira eu...@timbira.com:
Tom Lane escreveu:
That implies that the operations wouldn't work against system tables;
which they do. I think a bigger problem is that reset_single_table
seems like it might be talking about something like a TRUNCATE, ie,
it's not
On Sun, Jan 24, 2010 at 2:01 PM, Bernd Helmle maili...@oopsware.de wrote:
--On 24. Januar 2010 19:45:33 +0100 Bernd Helmle maili...@oopsware.de
wrote:
I don't see where this should be related to the number of tables not
part of the inheritance tree (or inheritance at all).
To answer that
On sön, 2010-01-24 at 19:43 +0200, Heikki Linnakangas wrote:
PREPARE TRANSACTION is not intended for use in applications or in
interactive sessions. It's purpose is to allow an external transaction
manager to perform atomic global transactions across multiple
databases
or other transactional
Robert Treat wrote:
On Saturday 23 January 2010 16:19:11 Andrew Dunstan wrote:
Robert Treat wrote:
I'm not saying there aren't
downsides, but having a name the community can unify on is a definite
plus, and imho that name has to be Postgres.
Translation: we'll only be unified
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Hmm, that's a good point though. Maybe it would make sense to add tab
completion for ROLLBACK/COMMIT PREPARED, but not for PREPARE TRANSACTION?
Huh? PREPARE TRANSACTION creates a new gxid, so there's nothing for
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Andrew Dunstan and...@dunslane.net wrote:
As for getting more coverage of Beta, part of my trouble in
testing applications on Beta is that there aren't good tools I
know of for capture and replay of usage scenarios. Now there would
be a
Peter Eisentraut wrote:
What is the
difference between a transaction manager and an application that opens
multiple connections and does PREPARE + COMMIT PREPARED across them?
It's what happens if your application crashes after issuing the PREPARE.
A correctly configured transaction manager
David Fetter just pointed this thread out to me. I think anything
that makes PostgreSQL more accessible could be a good thing. In some
sense it's harder to learn a technology when you are very familiar
with another similar one already. Is it easier to learn to type on
Dvorak, or to learn QWERTY
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Right, I vaguely recall that the idea of tab-completion for those
commands was rejected when 2PC was added because of that. A user sitting
at a psql terminal is not supposed to prepare a
Why do we have a parameter called default_do_language when we don't
have a parameter called default_language?
This is remarkably inconsistent. Why the difference? 5 years from now,
whatever reason we had will seem just strange.
Please can we have default_language? Or language_path so we can
On Sun, Jan 24, 2010 at 12:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Jan 24, 2010 at 12:06 AM, Jaime Casanova
why not let it go in ANALYZE, just as the sort info
It's kinda long-winded - it adds like 4 extra lines for each hash
join. I don't
On Sun, 2010-01-24 at 20:32 +, Simon Riggs wrote:
Or language_path so we can tell
CREATE FUNCTION to try the languages in order? Or better still, try all
the installed languages that the user has rights to in alphabetic
order?
What do you mean try? It seems a little dangerous to just try
Simon Riggs si...@2ndquadrant.com writes:
Please can we have default_language?
That sounds like something I could want to use someday.
Or language_path so we can tell
CREATE FUNCTION to try the languages in order? Or better still, try all
the installed languages that the user has rights to
Robert Haas robertmh...@gmail.com writes:
Care to suggest a format?
As much like the sort case as possible ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Jeff Davis pg...@j-davis.com writes:
I would actually lean the other way and say that we shouldn't be
introducing behavior-changing GUCs (except for the special case of
supporting legacy behavior, like standard_conforming_strings).
Yeah --- GUCs that affect semantics (as opposed to
On Jan 24, 2010, at 2:04 PM, Tom Lane wrote:
I don't see any strong argument for having a default for CREATE
FUNCTION. The original argument for having a GUC for DO was that
plpgsql wasn't built in; now that it is, I think a case could
be made for dropping default_do_language in favor of a
2010/1/24 Baron Schwartz ba...@xaprb.com:
David Fetter just pointed this thread out to me. I think anything
that makes PostgreSQL more accessible could be a good thing. In some
sense it's harder to learn a technology when you are very familiar
with another similar one already. Is it easier
I wrote:
I don't actually have a horse in this race, I can live with either name.
In the interests of full disclosure, I should point out that I in fact
do have a horse in the race, although I wasn't thinking of it when I
wrote the above. As an officer in a corporation with PostgreSQL in
On 01/21/2010 11:19 PM, Heikki Linnakangas wrote:
Joe Conway wrote:
OK, so now I see why we want this fixed for dblink and walreceiver, but
doesn't this approach leave every other WIN32 libpq client out in the
cold? Is there nothing that can be done for the general case, or is it a
SMOP?
2010/1/24 Joe Conway m...@joeconway.com:
On 01/21/2010 11:19 PM, Heikki Linnakangas wrote:
Joe Conway wrote:
OK, so now I see why we want this fixed for dblink and walreceiver, but
doesn't this approach leave every other WIN32 libpq client out in the
cold? Is there nothing that can be done
Magnus Hagander mag...@hagander.net writes:
2010/1/24 Joe Conway m...@joeconway.com:
Sorry for being thick -- I'm still missing something. I don't understand
why any user program using libpq/PQexec running on Windows does not have
the same issue. Or to put it another way, why does this only
On Sun, 2010-01-24 at 17:04 -0500, Tom Lane wrote:
If we have a default (for DO and CREATE FUNCTION), why not hard-wire the
default to plpgsql?
I don't see any strong argument for having a default for CREATE
FUNCTION. The original argument for having a GUC for DO was that
plpgsql wasn't
(2010/01/25 4:01), Bernd Helmle wrote:
--On 24. Januar 2010 19:45:33 +0100 Bernd Helmle maili...@oopsware.de
wrote:
I don't see where this should be related to the number of tables not
part of the inheritance tree (or inheritance at all).
To answer that myself: it seems get_attname()
On Sun, Jan 24, 2010 at 11:18 PM, Simon Riggs si...@2ndquadrant.com wrote:
I would prefer having the option, but removing it completely does at
least solve the bizarre inconsistency I've highlighted.
I don't see it as much of an inconsistency. The whole point of DO is
to be convenient, whereas
Greg Stark wrote:
On Sun, Jan 24, 2010 at 11:18 PM, Simon Riggs si...@2ndquadrant.com wrote:
I would prefer having the option, but removing it completely does at
least solve the bizarre inconsistency I've highlighted.
I don't see it as much of an inconsistency. The whole point of
Hi Cédric,
On Sun, Jan 24, 2010 at 5:11 PM, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
'psql --help mysql' (or 'psql --tips mysql' ) might be good to call a
special helper : I don't see the point to introduce that kind of
things when it is useless for most of our users.
I think
Dimitri Fontaine wrote:
And there's already pgfouine to get the scenarios from the logs and
tsung to act as a recording proxy:
http://pgfouine.projects.postgresql.org/tsung.html
http://tsung.erlang-projects.org/user_manual.html#htoc34
So maybe it would be a good idea to have dtester able
On Sun, 2010-01-24 at 23:59 +, Greg Stark wrote:
On Sun, Jan 24, 2010 at 11:18 PM, Simon Riggs si...@2ndquadrant.com wrote:
I would prefer having the option, but removing it completely does at
least solve the bizarre inconsistency I've highlighted.
I don't see it as much of an
I found a couple of incomplete syntax when I was adjusting psql
automatic tab completion for HEAD.
1. We cannot specify tablespace options on CREATE TABLESPACE
though ALTER TABLESPACE supports generic options by SET (...).
2. Should we still support ALTER COLUMN SET STATISTICS
though we
(2010/01/25 8:45), KaiGai Kohei wrote:
(2010/01/25 4:01), Bernd Helmle wrote:
--On 24. Januar 2010 19:45:33 +0100 Bernd Helmlemaili...@oopsware.de
wrote:
I don't see where this should be related to the number of tables not
part of the inheritance tree (or inheritance at all).
To answer
On 1/19/10 9:28 AM, Greg Smith wrote:
Takahiro Itagaki wrote:
The conclusion is splitting existing projects into some 'modules',
and getting the modules one by one into core. Voted features are here:
http://wiki.postgresql.org/wiki/ClusterFeatures
This page was a bit messy for someone who
Greg Stark wrote:
Tom Lane wrote:
What I think we really need for beta, and could reasonably hope to
get, is a larger and better-organized beta testing effort. But we
are not going to get that if people are thinking about new
development and commit fests instead of testing what's already
On 1/19/10 9:28 AM, Greg Smith wrote:
Takahiro Itagaki wrote:
The conclusion is splitting existing projects into some 'modules',
and getting the modules one by one into core. Voted features are here:
http://wiki.postgresql.org/wiki/ClusterFeatures
splitting existing projects into some
(2010/01/24 23:29), Magnus Hagander wrote:
2010/1/20 KaiGai Koheikai...@ak.jp.nec.com:
(2010/01/20 0:19), Magnus Hagander wrote:
* I think this comment is right.
+ for (i = 0; iRADIUS_VECTOR_LENGTH; i++)
+ /* XXX: Generate a more secure random string? */
+
Tatsuo Ishii is...@postgresql.org wrote:
splitting existing projects into some 'modules', and getting the
modules one by one into core was not the concluion, actually.
For example, see below from above URL: This means that we expect
PostgreSQL exports it's parser so that existing cluster
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
Tatsuo Ishii is...@postgresql.org wrote:
For example, see below from above URL: This means that we expect
PostgreSQL exports it's parser so that existing cluster softwares can
use it. Not opposite direction.
I think they says the same
2010/1/24 KaiGai Kohei kai...@ak.jp.nec.com:
It seems to me the result is different from Bernd's report.
Well, you tested something different, so you got a different answer.
Your case doesn't have any multiple inheritance.
...Robert
--
Sent via pgsql-hackers mailing list
Tom Lane t...@sss.pgh.pa.us wrote:
It's going to be a really, really, *really* hard sell to get us to
export any sort of external API to the parser internals. At least
if by API you mean something other than we will whack this around
to an indefinite degree on no notice, and don't even
I don't think. When we have function, with same parameters, same
behave like some Oracle function, then I am strongly prefer Oracle
name. I don't see any benefit from different name. It can only confuse
developers and add the trable to people who porting applications.
Meh. If the name is
(2010/01/25 14:08), Robert Haas wrote:
2010/1/24 KaiGai Koheikai...@ak.jp.nec.com:
It seems to me the result is different from Bernd's report.
Well, you tested something different, so you got a different answer.
Your case doesn't have any multiple inheritance.
If it tries ALTER TABLE xxx
1 - 100 of 106 matches
Mail list logo
