On 21 Nov 2009, at 02:56, Josh Berkus wrote:
Would a patch that changes that have any chance of being accepted? Or is
the gain (not having to repeat the DEFAULT clause, and being able to
maintain it at one place instead of many) considered too small compared
to the risk of breaking
Hello,
I am still thinking, about using DO statement from psql console. I am
missing any parametrisation. It could not be a problem. All pl have a
support for parameters, we have a libpq function PQexecParams - so we
need only some USING clause. I propose following syntax (and using
from client
2009/11/21 Pavel Stehule pavel.steh...@gmail.com:
Hello,
I am still thinking, about using DO statement from psql console. I am
missing any parametrisation. It could not be a problem. All pl have a
support for parameters, we have a libpq function PQexecParams - so we
need only some USING
On lör, 2009-11-14 at 14:50 +0100, Zdenek Kotala wrote:
Peter Eisentraut píše v so 14. 11. 2009 v 10:41 +0200:
On tor, 2009-09-17 at 21:43 +0200, Zdenek Kotala wrote:
Attached patch extends pg_ctl command with init option.
pg_ctl -D /var/lib/postgres [-s] init
This should
From: David E. Wheeler da...@justatheory.com
As I threatened when I reviewed hstore in the last two commit
fests, I've finally seen may way to edit the documentation. This
is mostly word-smithing, making sure that all ``s are encoded,
making sure that various text is properly tagged with `type`
Pavel Stehule wrote:
What do you thing about this proposal?
I think it's premature. Before we start adding bells and whistles to the
feature, let's give it a turn in the field.
One possible problem: what type would these anonymous params be? (And,
BTW, don't kid yourself that there
2009/11/21 Andrew Dunstan and...@dunslane.net:
Pavel Stehule wrote:
What do you thing about this proposal?
I think it's premature. Before we start adding bells and whistles to the
feature, let's give it a turn in the field.
why? It thing so not. My opinion - it is incomplete. It has
Pavel Stehule wrote:
p.s. Maybe it is premature - We had to live with EXECUTE (without
USING clause) twelve years. But an life should be comfortable. I don't
would to wait twelve years :)
I think you should take heed of Tom's words:
I think adding onto DO capabilities is something we
Pavel Stehule pavel.steh...@gmail.com writes:
2009/11/21 Andrew Dunstan and...@dunslane.net:
One possible problem: what type would these anonymous params be?
It is solved long time - without specification, any parameter is
'unknown text'.
Nonsense.
We do have the ability to infer parameter
Josh Berkus j...@agliodbs.com writes:
(2) this change, while very useful, does change what had been a simple
rule (All variables are NULL unless specifically set otherwise) into a
conditional one (All variables are NULL unless set otherwise OR unless
they are declared as domain types with
On Sat, Nov 21, 2009 at 7:26 AM, Josh Berkus j...@agliodbs.com wrote:
Would a patch that changes that have any chance of being accepted? Or is
the gain (not having to repeat the DEFAULT clause, and being able to
maintain it at one place instead of many) considered too small compared
to
I wrote:
The nice thing about XMLTABLE is that it adds xquery support. I think
the majority of xquery engines seem to be written in Java. XQuilla is
C++. I'm not sure if our licensing is compatible, but it I would love
the irony of using Berkeley DB XML (formerly Sleepycat) now that its
2009/11/21 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/11/21 Andrew Dunstan and...@dunslane.net:
One possible problem: what type would these anonymous params be?
It is solved long time - without specification, any parameter is
'unknown text'.
Nonsense.
I don't see point in having parameters for DO as an utility command. If
you need to reuse some value you can define those variables at the
beginning of code block in the language itself (in DECLARE section in
plpgsql for example), defining them in outer SQL command does not really
help
2009/11/21 Petr Jelinek pjmo...@pjmodos.net:
I don't see point in having parameters for DO as an utility command. If you
need to reuse some value you can define those variables at the beginning of
code block in the language itself (in DECLARE section in plpgsql for
example), defining them in
Pavel Stehule wrote:
I would to use this
statement for some non trivial maintenance tasks - and I would to use
external parameter (from command line). My question is - what is a
good way for passing some value (from command line) to DO statement
body? I accept any mechanism.
See my
VACUUM FULL does a peculiar hack: once it's done moving tuples, and
before it truncates the relation, it calls RecordTransactionCommit to
mark the transaction as committed in clog and WAL, but the transaction
is still kept open in proc array. After it's done with truncating and
other cleanup,
On Sat, Nov 21, 2009 at 12:36 PM, Andrew Dunstan and...@dunslane.net wrote:
Perhaps part of the problem is that psql can't interpolate its variable
into strings. Solving that might lessen the impetus for this, and have other
uses besides.
+1!
This would have a _lot_ of uses.
merlin
--
Sent
2009/11/21 Merlin Moncure mmonc...@gmail.com:
On Sat, Nov 21, 2009 at 12:36 PM, Andrew Dunstan and...@dunslane.net wrote:
Perhaps part of the problem is that psql can't interpolate its variable
into strings. Solving that might lessen the impetus for this, and have other
uses besides.
+1!
On Sat, Nov 21, 2009 at 1:24 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2009/11/21 Merlin Moncure mmonc...@gmail.com:
On Sat, Nov 21, 2009 at 12:36 PM, Andrew Dunstan and...@dunslane.net wrote:
Perhaps part of the problem is that psql can't interpolate its variable
into strings. Solving
2009/11/21 Merlin Moncure mmonc...@gmail.com:
On Sat, Nov 21, 2009 at 1:24 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2009/11/21 Merlin Moncure mmonc...@gmail.com:
On Sat, Nov 21, 2009 at 12:36 PM, Andrew Dunstan and...@dunslane.net
wrote:
Perhaps part of the problem is that psql
Heikki Linnakangas wrote:
So I guess what I'm asking is: Does anyone see any show-stoppers in
removing VACUUM FULL
Here's the disclaimers attached to the new VACUUM REPLACE implementation
from Itagaki:
We still need traditional VACUUM FULL behavior for system catalog
because we cannot change
Andrew Dunstan and...@dunslane.net writes:
See my earlier comment:
Perhaps part of the problem is that psql can't interpolate its
variable into strings. Solving that might lessen the impetus for this,
and have other uses besides.
It seems to me that this is sliding down the wrong slope.
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
So I guess what I'm asking is: Does anyone see any show-stoppers in
removing VACUUM FULL, and does anyone want to step up to the plate and
promise to do it before release?
I don't see much problem with rejecting VAC FULL in a HS
The main limitation of this type of approach is that it's hard to
properly quote a variable value that might contain any random character
sequence. However, that's also true of the variable-interpolation stuff
Pavel was proposing. In any case I don't think that getting stuff from
psql
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
So I guess what I'm asking is: Does anyone see any show-stoppers in
removing VACUUM FULL, and does anyone want to step up to the plate and
promise to do it before release?
I don't see much problem with rejecting
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
I don't see much problem with rejecting VAC FULL in a HS master,
whether or not it gets removed altogether. Why not just do that
rather than write a lot of kluges?
Hmm. At the moment, no action is required in the
Pavel Stehule pavel.steh...@gmail.com writes:
Hypothetically - when we are able to pass any value to DO script, then
I don't see problem. If I use Andrew's design - ${shellvar} and add it
to psql parser, then I could to write
\set par1 world
do $$
begin
raise notice 'Helo, % and %',
Tom Lane wrote:
In any case I don't think that getting stuff from
psql variables into a DO script is the way to define the problem.
It's getting stuff from shell variables into a DO script that is the
real-world problem.
Indeed. But setting psql variables from the command line is easy. We
On Fri, Nov 20, 2009 at 07:02:11PM -0500, Tom Lane wrote:
Upon poking around in the ecpg sources, I discover that it has its own
list of unreserved keywords and pays no attention whatsoever to the
core grammar's unreserved_keyword list. I can hardly find words to
express my dissatisfaction
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
I don't see much problem with rejecting VAC FULL in a HS master,
whether or not it gets removed altogether. Why not just do that
rather than write a lot of kluges?
Hmm. At the moment, no action
2009/11/21 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
Hypothetically - when we are able to pass any value to DO script, then
I don't see problem. If I use Andrew's design - ${shellvar} and add it
to psql parser, then I could to write
\set par1 world
do $$
On Sat, Nov 21, 2009 at 3:32 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2009/11/21 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
Hypothetically - when we are able to pass any value to DO script, then
I don't see problem. If I use Andrew's design - ${shellvar}
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 CLUSTER or COPY, which is a big optimization. I don't
see anything like that in Hot
2009/11/21 Merlin Moncure mmonc...@gmail.com:
On Sat, Nov 21, 2009 at 3:32 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2009/11/21 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
Hypothetically - when we are able to pass any value to DO script, then
I don't
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 that
defines the values to be yes or no, but then further
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 CLUSTER or COPY, which is a big optimization. I don't
see anything
Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
(2) this change, while very useful, does change what had been a
simple rule (All variables are NULL unless specifically set
otherwise) into a conditional one (All variables are NULL unless
set otherwise OR unless they are declared as domain
Gurjeet Singh wrote:
On Sat, Nov 21, 2009 at 7:26 AM, Josh Berkus j...@agliodbs.com
mailto:j...@agliodbs.com wrote: However, there are some other
issues to be resolved:
(1) what should be the interaction of DEFAULT parameters and domains
with defaults?
The function's DEFAULT parameter
pg_regress compares expected and actual output using diff -w
(a/k/a --ignore-all-space). We have always done this, and I think
the idea was to avoid getting a lot of useless diff noise when the
only real difference is that one column value in a tabular display is
wider than expected. I'm
On Nov 22, 2009, at 7:49 AM, Tom Lane wrote:
I'm thinking maybe we should remove -w. Comments?
Have you tried it on the existing tests to see what happens?
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On lör, 2009-11-21 at 22:20 +0100, Florian G. Pflug wrote:
I'm inclined to leave it alone. It complicates the mental model, and
frankly attaching defaults to domains was not one of the SQL
committee's better ideas anyway. It's *fundamentally*
non-orthogonal.
I've always though of
Emmanuel Cecchet wrote:
Hi Jan,
Here is the updated patch.
Note that the new code in trigger is a copy/paste of the before row
insert trigger code modified to use the pointers of the after row
trigger functions.
Hi,
ok, this version applied, compiled and ran the regression tests fine. I
On mån, 2009-11-16 at 22:37 +0200, Peter Eisentraut wrote:
On ons, 2009-10-21 at 13:11 +0900, Itagaki Takahiro wrote:
Sure. Client encoding is declared in body of a file, but BOM is
in head of the file. So, we should always ignore BOM sequence
at the file head no matter what client encoding
On Sat, Nov 21, 2009 at 16:07, David E. Wheeler da...@kineticode.com wrote:
On Nov 22, 2009, at 7:49 AM, Tom Lane wrote:
I'm thinking maybe we should remove -w. Comments?
Have you tried it on the existing tests to see what happens?
For me there I get:
*the breaking in create_cast
*various
Roger Leigh rle...@codelibre.net writes:
Attached is an updated patch with a couple of tweaks to ensure output
is formatted and spaced correctly when border=0, which was off in the
last patch.
Applied wih minor editorialization. Notably, I renamed the
backwards-compatible option from
Jan Urbański wrote:
o) my main concern is still valid: the design was never agreed upon.
The approach of using inheritance info for automatic partitioning is, at
least IMHO, too restricted. Regular INSERTs won't get routed to child
tables. Data from writable CTEs won't get routed. People
Jan Urbański wrote:
o) my main concern is still valid: the design was never agreed upon.
The approach of using inheritance info for automatic partitioning is, at
least IMHO, too restricted. Regular INSERTs won't get routed to child
tables. Data from writable CTEs won't get routed. People
48 matches
Mail list logo
