On 02/02/2011 08:22 PM, Dimitri Fontaine wrote:
Either one line in the Makefile or a new file with the \i equivalent
lines, that would maybe look like:
SELECT pg_execute_sql_file('upgrade.v14.sql');
SELECT pg_execute_sql_file('upgrade.v15.sql');
So well… I don't see how you've made it
On 02/03/2011 12:23 AM, Robert Haas wrote:
[..]
-- unconditional stuff
[..6]
-- stuff to do if coming from pre-7
[..]
-- some more unconditional stuff
[6..12]
-- stuff to do if coming from between 6 and 12
[..]
-- a few more unconditional things
This might be a stupid idea, but how about
On Thu, Feb 3, 2011 at 04:40, Bruce Momjian br...@momjian.us wrote:
I am seeing the following compiler warning for the past few days:
basebackup.c:213: warning: variable `ptr' might be clobbered by
`longjmp' or `vfork'
and I see this comment in the file:
/*
*
Robert Haas robertmh...@gmail.com writes:
Stepping back from the implementation details and file naming
conventions a bit, it seems to me that when you do schema upgrades,
there are basically three possible things you might want to put in the
upgrade script:
[...]
I've managed schema upgrades
Anssi Kääriäinen anssi.kaariai...@thl.fi writes:
upgrade_from_2.0.sql contents:
alter table foobar add column id3 integer;
pg_execute_extension_file('upgrade_from_3.0.sql');
...
So, when creating a new version you would need to update the main .sql file,
create a new upgrade file, and
This might be a silly idea, but I'm not sure if it was really
discussed with respect to extensions here before...
Why not use PL/pgSQL as install/upgrade script language,
specially now when it's included in the core by default?
This would allow for relatively straightforward inclusion
of
Someone submitted a comment to the docs (which I'll shortly delete)
which points out a typo on the CREATE USER MAPPING page in the docs.
A very brief patch is attached.
They also added: Also concerning this paragraph: a little more detail
on how exactly the two sources of encapsuled information
On Wed, Feb 2, 2011 at 18:00, Magnus Hagander mag...@hagander.net wrote:
On Wed, Feb 2, 2011 at 17:43, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 02.02.2011 16:36, Magnus Hagander wrote:
When running pg_basebackup with -x to include all transaction log, the
server will
On Thu, Feb 3, 2011 at 11:07, Thom Brown t...@linux.com wrote:
Someone submitted a comment to the docs (which I'll shortly delete)
which points out a typo on the CREATE USER MAPPING page in the docs.
A very brief patch is attached.
Thanks, applied.
--
Magnus Hagander
Me:
Hi,
On Feb 2, 2011, at 7:16 PM, Tim Bunce wrote:
I'm sorry I'm late to this party. I haven't been keeping up with
pgsql-hackers.
Better late than never :)
I'd kind'a hoped that this functionality could be tied into extending
PL/Perl to handle named arguments. That way the perl variables
On Wed, Feb 02, 2011 at 07:48:38PM -0500, Bruce Momjian wrote:
Brendan Jurd wrote:
On 3 February 2011 10:54, Bruce Momjian br...@momjian.us wrote:
It seems LIKE is considering the trailing CHAR(10) field spaces as
significant, even though our documentations says:
-- snip --
It
On Thu, Feb 03, 2011 at 10:21:28AM +0200, Anssi Kääriäinen wrote:
On 02/02/2011 08:22 PM, Dimitri Fontaine wrote:
Either one line in the Makefile or a new file with the \i equivalent
lines, that would maybe look like:
SELECT pg_execute_sql_file('upgrade.v14.sql');
SELECT
On Thu, Feb 3, 2011 at 9:53 AM, Ross J. Reedstrom reeds...@rice.edu wrote:
Example:
upgrade_from_1_0 = '1.0 = upgrade_from_1.0.sql'
upgrade_from_2_0 = '2.0 = upgrade_from_2.0.sql'
upgrade_from_3_0 = '3.0 = upgrade_from_3.0.sql'
Hmm, how about allowing a list of files to execute? That allows
Ross J. Reedstrom reeds...@rice.edu writes:
Hmm, how about allowing a list of files to execute? That allows the
Sure. I still don't see why doing it in the control file is better than
in the Makefile, even if it's already better than in the SQL script, at
least in terms of code to write to
On Tue, Feb 1, 2011 at 5:32 AM, Tom Lanyon
tom+pgsql-hack...@oneshoeco.com wrote:
List,
Can anyone suggest where the below error comes from, given I'm attempting to
load HTTP access log data with reasonably small row and column value lengths?
logs=# COPY raw FROM
2011/1/31 Jürgen Wolfsgruber juergen.wolfsgru...@gmail.com:
Trying to start a telnet-connection, the result was:
telnet 127.0.0.1 5432
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Operation timed out
telnet: Unable to connect to remote host
That's just bizarre. How can you get
I have applied the attached patch to cleanup coding of the
is_absolute_path macro, and added documentation of how 'E:abc' is
handled on Win32.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for
On Wed, Feb 02, 2011 at 12:10:59PM -0500, Andrew Dunstan wrote:
On 02/02/2011 11:45 AM, Tim Bunce wrote:
But why are we bothering to keep $prolog at
all any more, if all we're going to pass it isPL_sv_no all the
time? Maybe we'll have a use for it in the future, but right now we
don't
On Thu, Feb 03, 2011 at 04:31:08PM +0100, Dimitri Fontaine wrote:
Ross J. Reedstrom reeds...@rice.edu writes:
Hmm, how about allowing a list of files to execute? That allows the
Sure. I still don't see why doing it in the control file is better than
in the Makefile, even if it's already
On Thu, Feb 3, 2011 at 11:25 AM, Ross J. Reedstrom reeds...@rice.edu wrote:
Speaking about which, using Make rules to prepare your upgrade files
from other pieces means no development at all on the backend side. You
can hardly beat that.
Yes, from the backend-developer's perspective. But not
=?iso-8859-2?Q?=AEiga_Kranjec?= z...@ljudmila.org writes:
This might be a silly idea, but I'm not sure if it was really
discussed with respect to extensions here before...
yes, it was ...
Why not use PL/pgSQL as install/upgrade script language,
specially now when it's included in the core
Bruce Momjian wrote:
However, it misses the case with for example E:foo, which is a perfectly
valid path on windows. Which isn't absolute *or* relative - it's relative
to the current directory on the E: drive. Which will be the same as the
current directory for the process *if* the process
On Feb 3, 2011, at 4:23 AM, Alexey Klyukin wrote:
- Making the conversion lazy would be a big help.
Converting it to string is already lazy, and, per the argumens above, I don't
see a real benefit of lazy conversion to the perl reference (as comparing to
the hurdles of implementing that).
Robert Haas robertmh...@gmail.com writes:
Yes, from the backend-developer's perspective. But not from the
extension-developer's perspective :-) And seriously, make is one of
those things that is supremely capable of doing lots of stuff, but is so
difficult to use correctly that everyone keeps
On Feb3, 2011, at 16:31 , Dimitri Fontaine wrote:
Ross J. Reedstrom reeds...@rice.edu writes:
Hmm, how about allowing a list of files to execute? That allows the
Sure. I still don't see why doing it in the control file is better than
in the Makefile, even if it's already better than in the
Kenneth Marshall k...@rice.edu writes:
On Wed, Feb 02, 2011 at 07:48:38PM -0500, Bruce Momjian wrote:
It seems LIKE is considering the trailing CHAR(10) field spaces as
significant, even though our documentations says:
+10 for leaving the behavior as is.
Yeah, we've been around on this
On Thu, Feb 3, 2011 at 11:53 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
Yes, from the backend-developer's perspective. But not from the
extension-developer's perspective :-) And seriously, make is one of
those things that is supremely capable
Bruce Momjian br...@momjian.us writes:
I have reviewed is_absolute_path() and have implemented
path_is_relative_and_below_cwd() to cleanly handle cases like 'E:abc' on
Win32; patch attached.
This patch appears to remove some security-critical restrictions.
Why did you delete the
Florian Pflug f...@phlo.org writes:
I fully agree. The extension infrastructure should provide basic support
for upgrades, not every kind of bell and whistle one could possible think of.
Maybe somewhere around here we should stop and ask why we are bothering
with any of this. The original idea
On Feb 3, 2011, at 9:38 AM, Tom Lane wrote:
Given that pg_upgrade is now considered a supported piece of the system,
ISTM that most real-world upgrade scenarios will be accomplished with
pg_upgrade relying on provision (3). It looks to me like we're talking
about adding a large amount of
On Thu, Feb 3, 2011 at 12:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org writes:
I fully agree. The extension infrastructure should provide basic support
for upgrades, not every kind of bell and whistle one could possible think of.
Maybe somewhere around here we should
On Thu, Feb 03, 2011 at 02:23:32PM +0200, Alexey Klyukin wrote:
Hi,
On Feb 2, 2011, at 7:16 PM, Tim Bunce wrote:
I'm sorry I'm late to this party. I haven't been keeping up with
pgsql-hackers.
Better late than never :)
I'd kind'a hoped that this functionality could be tied into
On Feb 3, 2011, at 9:54 AM, Robert Haas wrote:
I think you can pretty much take it to the bank that there will be
demand. This is an important, real-world problem.
That having been said, I'm not 100% convinced that the main extensions
patch is ready for prime-time, and I'm even less
David E. Wheeler da...@kineticode.com writes:
I think we will need to come back to it before, long, however, because many
extensions are released far more often than major versions of PostgreSQL. So
while one might run pg_upgrade, at most, about once every 12-18 months, they
will often want
On Feb 3, 2011, at 10:07 AM, Tom Lane wrote:
Well, pg_upgrade is designed to work within a major-version series, eg
you could do a 9.1-to-9.1 upgrade if you needed to install a newer
version of an extension. Admittedly, this is swinging a rather larger
hammer than apply an upgrade script
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I have reviewed is_absolute_path() and have implemented
path_is_relative_and_below_cwd() to cleanly handle cases like 'E:abc' on
Win32; patch attached.
This patch appears to remove some security-critical restrictions.
Why did you
On 02/03/2011 01:01 PM, Tim Bunce wrote:
Imagine that PL/Perl could handle named arguments:
CREATE FUNCTION join_list( separator text, list array ) AS $$
return join( $separator, @$list );
$$ LANGUAGE plperl;
The $list variable, magically created by PL/Perl, could be the
Tom Lane t...@sss.pgh.pa.us writes:
Maybe somewhere around here we should stop and ask why we are bothering
with any of this. The original idea for an extension concept was that
(1) some collection of objects could be designated as a module
(2) pg_dump would be taught to dump LOAD MODULE foo
On tor, 2011-02-03 at 18:01 +, Tim Bunce wrote:
Imagine that PL/Perl could handle named arguments:
CREATE FUNCTION join_list( separator text, list array ) AS $$
return join( $separator, @$list );
$$ LANGUAGE plperl;
The $list variable, magically created by PL/Perl,
Tom Lane t...@sss.pgh.pa.us writes:
Now having said that, it does occur to me that there is an upgrade-ish
scenario that every user is going to hit immediately, which is how to
get from an existing installation with a pile of loose objects created
by one or more contrib modules to a state
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I have reviewed is_absolute_path() and have implemented
path_is_relative_and_below_cwd() to cleanly handle cases like 'E:abc' on
Win32; patch attached.
This patch appears to remove some
On Thu, Feb 3, 2011 at 1:10 PM, David E. Wheeler da...@kineticode.com wrote:
On Feb 3, 2011, at 10:07 AM, Tom Lane wrote:
Well, pg_upgrade is designed to work within a major-version series, eg
you could do a 9.1-to-9.1 upgrade if you needed to install a newer
version of an extension.
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 3, 2011 at 1:10 PM, David E. Wheeler da...@kineticode.com wrote:
On Feb 3, 2011, at 10:07 AM, Tom Lane wrote:
Well, pg_upgrade is designed to work within a major-version series, eg
you could do a 9.1-to-9.1 upgrade if you needed to install
On Feb 3, 2011, at 11:02 AM, Tom Lane wrote:
That's putting it mildly. It's more like sending a rocket into outer
space to tweak the orbit of a comet so that it crashes into your
barbecue grill to light a fire so you can roast marshmallows.
LOL.
No, it's more like using a sledgehammer to
On Thu, Feb 3, 2011 at 2:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 3, 2011 at 1:10 PM, David E. Wheeler da...@kineticode.com
wrote:
On Feb 3, 2011, at 10:07 AM, Tom Lane wrote:
Well, pg_upgrade is designed to work within a major-version
All,
Let me summarize the prospective solutions based on some chatting with
some potential extension authors (that is, folks who maintain in-house
stuff they're thinking of offering as extensions). Especially since I
think at this point the majority of -hackers has lost track of the argument:
Josh Berkus j...@agliodbs.com writes:
Let me summarize the prospective solutions based on some chatting with
some potential extension authors (that is, folks who maintain in-house
stuff they're thinking of offering as extensions). Especially since I
think at this point the majority of
On Thu, Feb 3, 2011 at 05:23, Alexey Klyukin al...@commandprompt.com wrote:
Hi,
On Feb 2, 2011, at 7:16 PM, Tim Bunce wrote:
[...]
Some observations on the current code (based on a quick skim):
- I'd like to see the conversion function exposed as a builtin
$ref =
Well if you want to support upgrades between each two versions, that
means you have users and you don't know what they currently have
installed. Then you have this problem to solve, and it's complex the
same no matter what tools are offered.
How *are* we detecting which version is
Dne 30.1.2011 23:22, Robert Haas napsal(a):
On Thu, Dec 23, 2010 at 2:41 PM, Tomas Vondra t...@fuzzy.cz wrote:
OK, so here goes the simplified patch - it tracks one reset timestamp
for a background writer and for each database.
I think you forgot the attachment.
Yes, I did. Thanks!
This
On Sat, Jan 15, 2011 at 05:47:24AM -0500, Greg Smith wrote:
For example, the pre-release Squeeze numbers we're seeing are awful so
far, but it's not really done yet either.
Unfortunately, it does not look like Debian squeeze will change any more
(or has changed much since your post) at this
Josh Berkus j...@agliodbs.com writes:
(D) Requires a series of ordered upgrade scripts in sortable version
numbering, each of which gets applied in order between the two versions.
This initially seems like the most attractive option -- and is the one
used by dozens of popular open source web
On Feb 3, 2011, at 11:35 AM, Josh Berkus wrote:
(D) Requires a series of ordered upgrade scripts in sortable version
numbering, each of which gets applied in order between the two versions.
This initially seems like the most attractive option -- and is the one
used by dozens of popular open
FWIW, I think that last objection is bogus. There's no reason that an
extension author can't leave dummy C functions in his code to support
obsolete CREATE FUNCTION calls. (As an example, I added one to
Alexander Korotkov's recent pg_trgm patch. It consists of 10 lines of
boilerplate
On Thu, Feb 03, 2011 at 05:53:28PM +0200, Peter Eisentraut wrote:
On tor, 2011-02-03 at 00:10 -0500, Noah Misch wrote:
This is good stuff. I'll send you a new patch in a day or three for
perhaps another round of performance tests. Some of the other
issues
above can perhaps be
Revisiting this, it occurred to me that I could achieve what I need of
we extend the proposed API a bit. Currently, it has:
extern CopyState BeginCopyFrom(Relation rel, const char *filename,
List *attnamelist, List *options);
I'd like to be able to add
On Mon, Jan 31, 2011 at 01:34, Alexey Klyukin al...@commandprompt.com wrote:
I've looked at the patch and added a test for arrays exceeding or equal
maximum dimensions to check, whether the recursive function won't bring
surprises there. I've also added check_stack_depth calls to both
On Fri, Feb 4, 2011 at 09:48, Andrew Dunstan and...@dunslane.net wrote:
I'd like to be able to add a callback function to construct the values for
the tuple. So it would become something like:
typedef void (*copy_make_values) (CopyState cstate, NumFieldsRead int);
You can do nothing
Of course, I want this so I could construct a text array from the read in
data, but I could also imagine a foreign data wrapper wanting to mangle the
data before handing it to postgres, say by filling in a field or hashing it.
Could you explain the actual use-cases and examples? I think we
Thinking I should start with why I think this patch is neat...most of
the servers I deal with are up 24x7 minus small amounts of downtime,
presuming everyone does their job right that is. In that environment,
having a starting timestamp for when the last stats reset happened lets
you quickly
On Fri, Feb 4, 2011 at 11:32, Andrew Dunstan and...@dunslane.net wrote:
Umm, where? I can't find this in the documentation
http://pgbulkload.projects.postgresql.org/pg_bulkload.html
Here:
http://pgbulkload.projects.postgresql.org/pg_bulkload.html#filter
The object, as I have explained
On 02/03/2011 09:43 PM, Itagaki Takahiro wrote:
On Fri, Feb 4, 2011 at 11:32, Andrew Dunstanand...@dunslane.net wrote:
Umm, where? I can't find this in the documentation
http://pgbulkload.projects.postgresql.org/pg_bulkload.html
Here:
Robert Haas wrote:
At least in my book, we need to get this committed in the next two
weeks, or wait for 9.2.
Yes, I was just suggesting that I was not going to get started in the
first week or two given the other pgbench related tests I had queued up
already. Those are closing up
On Sun, Jan 30, 2011 at 6:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Just in a quick read-through of the patches, the only things I noticed
Oh, a third thing: the patch places errcodes.txt under src/include,
which does not seem even approximately right. src/backend/utils
seems like
On Sun, Jan 30, 2011 at 3:26 PM, Magnus Hagander mag...@hagander.net wrote:
Magnus, are you planning to get this committed for 9.1?
I'd like to, but I'm not sure I'll have the time. Per the comment from
Brar it was intended as an initial attempt not quite ready yet, so
it's not something we
On Fri, Feb 4, 2011 at 12:17, Andrew Dunstan and...@dunslane.net wrote:
http://pgbulkload.projects.postgresql.org/pg_bulkload.html#filter
AFAICT, this doesn't support ragged tables with too many columns, which is
my prime use case. If it supported variadic arguments in filter functions it
On Sun, Jan 30, 2011 at 10:26 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jan 30, 2011 at 10:03 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of dom ene 30 23:37:51 -0300 2011:
Unless I'm missing something, making autovacuum.c call
On Fri, Jan 14, 2011 at 6:15 AM, Simon Riggs si...@2ndquadrant.com wrote:
Patch to implement the proposed feature attached, for CFJan2011.
2 sub-command changes:
ALTER TABLE foo ADD FOREIGN KEY fkoo ... NOT VALID;
ALTER TABLE foo VALIDATE CONSTRAINT fkoo;
This patch, which seems to be the
Hi,
When I run git pull from the git master and make, I encountered
the following compilation error.
gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wformat-security
-fno-strict-aliasing -fwrapv -g -I../../src/port -I../../src/include
-D_GNU_SOURCE
On Thu, Feb 3, 2011 at 11:02 PM, Fujii Masao masao.fu...@gmail.com wrote:
Hi,
When I run git pull from the git master and make, I encountered
the following compilation error.
gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wformat-security
On Wed, Feb 2, 2011 at 13:32, Joachim Wieland j...@mcknight.de wrote:
Here is a rebased version with some minor changes as well.
I read the patch works as below. Am I understanding correctly?
1. Open all connections in a parent process.
2. Start transactions for each connection in the
On Thu, Feb 3, 2011 at 11:42 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Feb 3, 2011 at 11:02 PM, Fujii Masao masao.fu...@gmail.com wrote:
Hi,
When I run git pull from the git master and make, I encountered
the following compilation error.
gcc -Wall -Wmissing-prototypes
On Fri, Feb 4, 2011 at 12:11 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Feb 3, 2011 at 11:42 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Feb 3, 2011 at 11:02 PM, Fujii Masao masao.fu...@gmail.com wrote:
Hi,
When I run git pull from the git master and make, I encountered
On Tue, Feb 1, 2011 at 13:08, Hitoshi Harada umi.tan...@gmail.com wrote:
The third patch is attached, modifying mb routines so that they can
receive conversion procedures as FmgrInof * and save the function
pointer in CopyState.
I tested it with encoding option and could not see performance
On 02/03/2011 10:43 PM, Itagaki Takahiro wrote:
Also, a FDW allows the COPY to be used as a FROM target, giving it great
flexibility. AFAICT this does not.
BTW, which do you want to improve, FDW or COPY FROM? If FDW, the better
API would be raw version of NextCopyFrom(). For example:
75 matches
Mail list logo
