Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Hoo, nasty. Tcl_GetVar() is resetting interp-result.
According to the manual page that's only supposed to happen if the
TCL_LEAVE_ERR_MSG flag is used:
TCL_LEAVE_ERR_MSG
If an error is
On Monday 16 June 2008 21:12:23 Andrew Dunstan wrote:
David Fetter wrote:
On Mon, Jun 16, 2008 at 06:00:33PM -0400, Andrew Dunstan wrote:
I, too, would be happy to do the legwork on this one. I believe
we'd want to have both per-db and per-role settings for
search_path. What's involved
On Jun 16, 2008, at 3:35 PM, Tom Lane wrote:
to a cache entry rather than a freshly palloc'd value. The cache
lookup
key is the toast table OID plus value OID. Now pg_detoast_datum()
has no
...
the result of decompressing an inline-compressed datum, because
those have
no unique ID
Robert Treat wrote:
On Monday 16 June 2008 21:12:23 Andrew Dunstan wrote:
David Fetter wrote:
On Mon, Jun 16, 2008 at 06:00:33PM -0400, Andrew Dunstan wrote:
I, too, would be happy to do the legwork on this one. I believe
we'd want to have both per-db and per-role settings
The example here
http://archives.postgresql.org/pgsql-novice/2008-06/msg00025.php
shows that we are failing to regenerate cached plans when a table
referenced by a regclass constant is removed. This is pretty minor
in the big scheme of things, but it's still annoying since there is
code in there
Jeff [EMAIL PROTECTED] writes:
On Jun 16, 2008, at 3:35 PM, Tom Lane wrote:
the result of decompressing an inline-compressed datum, because those
have no unique ID that could be used for a lookup key. This puts a
bit of a
Wouldn't the tid fit this? or table oid + tid?
No. The killer
Folks,
I've noticed that a big hunk of our build system has gratuitous
dependencies on some variety of shell and on tools like sed, none of
which makes Windows developers feel welcome. I know people are
working toward a cmake or other more cross-platform toolchain.
My proposal is a lot more
David Fetter wrote:
Folks,
I've noticed that a big hunk of our build system has gratuitous
dependencies on some variety of shell and on tools like sed, none of
which makes Windows developers feel welcome. I know people are
working toward a cmake or other more cross-platform toolchain.
My
David Fetter [EMAIL PROTECTED] writes:
My proposal is a lot more modest, and doesn't conflict with the larger
one. I'd like to move the above stuff to self-contained perl would
help to make things more cross-platform and clean up, no offense to
the fine authors, some pretty crufty code in
On Mon, Jun 16, 2008 at 09:43:37PM -0400, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
David Fetter wrote:
Maybe I'm missing something big, but I don't quite see what
constitutes proper that doesn't involve the module's having at
least one schema to itself.
ISTM that
David Fetter wrote:
It's not quite that simple. Let's say you're *developing* a module.
I don't see any way to play with it in the separate module proposal,
where I *do* see a whole extra non-orthogonal feature where none is
needed. No way to do optional submodules, either, and I'm sure
On Tue, Jun 17, 2008 at 10:19:59AM -0400, Andrew Dunstan wrote:
David Fetter wrote:
Folks,
I've noticed that a big hunk of our build system has gratuitous
dependencies on some variety of shell and on tools like sed, none
of which makes Windows developers feel welcome. I know people are
Alvaro Herrera [EMAIL PROTECTED] writes:
Maybe what's needed here is just some more additional commands (i.e.
add this function to the module, this module is dependent on this
other module).
Yeah. Didn't we have this discussion already?
regards, tom lane
--
Sent via
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Maybe what's needed here is just some more additional commands (i.e.
add this function to the module, this module is dependent on this
other module).
Yeah. Didn't we have this discussion already?
I don't know -- I skipped it.
David Fetter wrote:
On Tue, Jun 17, 2008 at 10:19:59AM -0400, Andrew Dunstan wrote:
David Fetter wrote:
Folks,
I've noticed that a big hunk of our build system has gratuitous
dependencies on some variety of shell and on tools like sed, none
of which makes Windows developers feel
David Fetter wrote:
That new version stamper calls out to sed, when perl is perfectly
capable of doing the same work itself and not spawning 30 shells in
the process.
That's great. Please send a patch to improve the stamper. (Are you
really worried about its performance, given that it runs
David Fetter wrote:
On Tue, Jun 17, 2008 at 10:19:59AM -0400, Andrew Dunstan wrote:
David Fetter wrote:
Folks,
Well, it'll wind up with a build system that's documented a lot better
than it is :)
Is perl currently required to build from tarball? If not, you would
be placing an additional
On Tue, Jun 17, 2008 at 11:00:31AM -0400, Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Maybe what's needed here is just some more additional commands
(i.e. add this function to the module, this module is
dependent on this other module).
Yeah.
David Fetter wrote:
Yeah. Didn't we have this discussion already?
I don't know -- I skipped it. Sorry. Blame it on Dave Fetter :-P
Everything is my fault :)
You finally understand!
Joshua D. Drake
Cheers,
David.
--
Sent via pgsql-hackers mailing list
David Fetter [EMAIL PROTECTED] writes:
It's not quite that simple. Let's say you're *developing* a module.
I don't see any way to play with it in the separate module proposal,
where I *do* see a whole extra non-orthogonal feature where none is
needed.
The claim that no new feature is needed
Alvaro Herrera [EMAIL PROTECTED] writes:
David Fetter wrote:
This is 2008, and it's silly to pretend we need to support this
requirement on systems where people are building Postgres.
Maybe, or maybe not. Do these platforms all have Perl?
In this connection it might be worth pointing to the
On Tue, 17 Jun 2008, Alvaro Herrera wrote:
Maybe, or maybe not. Do these platforms all have Perl?
Of course. They're all buildfarm clients and the buildfarm script is
perl.
Kris Jurka
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
It is impossible to dump (with pg_dump -Ocx) and restore (with psql) a
database which contains sequences in any of 8.1, 8.2, or 8.3:
[...]
--
-- Name: transaction_transaction_id_seq; Type: SEQUENCE SET; Schema:
mercado; Owner: prod
--
SELECT
There was a discussion back here:
http://archives.postgresql.org/pgsql-bugs/2008-01/msg00189.php
that came to the conclusion that cross-type operators are a bad idea
if they don't come in complete sets: if you don't have an exact match
to the input types, and there are multiple possible
Jeffrey Baker [EMAIL PROTECTED] writes:
It is impossible to dump (with pg_dump -Ocx) and restore (with psql) a
database which contains sequences in any of 8.1, 8.2, or 8.3:
I should think we would have heard about it before now if such a
sweeping claim were true.
What I suspect is that you are
But we can resolve that by ruling that the required lifetime is the same
as the value would have had if it'd really been palloc'd --- IOW, until
the memory context that was current at the time gets deleted or reset.
Many support functions of GiST/GIN live in very short memory context - only
Teodor Sigaev [EMAIL PROTECTED] writes:
But we can resolve that by ruling that the required lifetime is the same
as the value would have had if it'd really been palloc'd --- IOW, until
the memory context that was current at the time gets deleted or reset.
Many support functions of GiST/GIN
On Tue, Jun 17, 2008 at 01:29:56PM -0400, Tom Lane wrote:
...
What I'm inclined to do is remove the two % operators, which don't seem
likely to be performance-critical, and fill in the missing int2-vs-int8
cases for the four basic arithmetic operators. But I could be talked
into just nuking
On Tue, Jun 17, 2008 at 10:59 AM, Tom Lane [EMAIL PROTECTED] wrote:
Jeffrey Baker [EMAIL PROTECTED] writes:
It is impossible to dump (with pg_dump -Ocx) and restore (with psql) a
database which contains sequences in any of 8.1, 8.2, or 8.3:
I should think we would have heard about it
I definitely think it's worth it, even if it doesn't handle an
inline-compressed datum.
Yeah. I'm not certain how much benefit we could get there anyway.
If the datum isn't out-of-line then there's a small upper limit on how
big it can be and hence a small upper limit on how long it takes
Jeffrey Baker escribió:
On Tue, Jun 17, 2008 at 10:59 AM, Tom Lane [EMAIL PROTECTED] wrote:
Jeffrey Baker [EMAIL PROTECTED] writes:
It is impossible to dump (with pg_dump -Ocx) and restore (with psql) a
database which contains sequences in any of 8.1, 8.2, or 8.3:
I should think we
On Tue, Jun 17, 2008 at 2:43 PM, Alvaro Herrera [EMAIL PROTECTED]
wrote:
Jeffrey Baker escribió:
On Tue, Jun 17, 2008 at 10:59 AM, Tom Lane [EMAIL PROTECTED] wrote:
Jeffrey Baker [EMAIL PROTECTED] writes:
It is impossible to dump (with pg_dump -Ocx) and restore (with psql)
a
Jeffrey Baker escribió:
The table was originally created this way:
CREATE TABLE transaction
(
transaction_id SERIAL PRIMARY KEY,
buyer_account_idINTEGER,
seller_account_id INTEGER,
dateDATE,
Alvaro Herrera wrote:
Maybe, or maybe not. Do these platforms all have Perl?
gypsy_moth Solaris 8 SUN Studio 8 spar
If the moths don't have perl, we'll add it, no problem - don't let that
stop anything.
(On a separate note, we have had some problems internally with DNS, so
some
Jorgen Austvik wrote:
Alvaro Herrera wrote:
Maybe, or maybe not. Do these platforms all have Perl?
gypsy_moth Solaris 8 SUN Studio 8 spar
If the moths don't have perl, we'll add it, no problem - don't let
that stop anything.
Of course they have perl - the buildfarm script is perl.
Folks,
I'm doing some analysis of PostgreSQL site traffic, and am being frequently
hung up by the compile-time-fixed size of our regex cache (32 regexes, per
MAX_CACHED_RES). Is there a reason why it would be hard to use work_mem
or some other dynamically changeable limit for regex caching?
Alvaro Herrera [EMAIL PROTECTED] writes:
Jeffrey Baker escribió:
The table was originally created this way:
Okay, but was it created on 8.1 or was it already created on an older
version and restored? I don't see this behavior if I create it in 8.1
-- the field is dumped as SERIAL, unlike
On Tue, Jun 17, 2008 at 6:31 PM, Tom Lane [EMAIL PROTECTED] wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Jeffrey Baker escribió:
The table was originally created this way:
Okay, but was it created on 8.1 or was it already created on an older
version and restored? I don't see this
Coming to this thread a bit late as I've been out of email
connectivity for the past week...
On Tue, Jun 17, 2008 at 2:43 AM, Tom Lane [EMAIL PROTECTED] wrote:
In any case, trying to define a module as a schema doesn't help at all
to solve the hard problem, which is how to get this stuff to
Josh Berkus [EMAIL PROTECTED] writes:
I'm doing some analysis of PostgreSQL site traffic, and am being frequently
hung up by the compile-time-fixed size of our regex cache (32 regexes, per
MAX_CACHED_RES). Is there a reason why it would be hard to use work_mem
or some other dynamically
40 matches
Mail list logo
