Tom Lane wrote:
That's an artifact of the fact that the patch tries to piggyback on
the DOMAIN infrastructure instead of implementing its own statement
type etc.
This piggybacking is intentional in some way. If you read the
commentary on the SQL99 standard, distinct types were specifically
I've been slicing and dicing this patch for the last few days. There's a
lot of code in there, but here's some initial comments:
The code to initialize, advance, and finalize an aggregate should be
shared between Agg and Window nodes.
I'm a bit disappointed that we need so much code to
Alvaro Herrera [EMAIL PROTECTED] writes:
However, your idea suggests something else that we could do to improve
the patch: skip the ItemId-lp_flags during the CRC calculation. This
would mean we wouldn't need to WAL-log those.
What!? In most cases those bits are critical data, not hints.
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
However, your idea suggests something else that we could do to improve
the patch: skip the ItemId-lp_flags during the CRC calculation. This
would mean we wouldn't need to WAL-log those.
What!? In most cases those bits are
It was pointed out to me today that a zero-dimensional matrix is a scalar.
This makes a bit of sense, if you say that
'{{56}}' is of type int[][], 2 dimensions
'{56}' is of type int[], 1 dimension
'56' is of type int, 0 dimensions
Notice that the number of brace pairs in the literal
Sergey Konoplev [EMAIL PROTECTED] writes:
You are right. I've found the odd thing (that completely drives me
mad) in postgresql.conf.
You are able to reproduce slow-not-in queries by switching
constraint_exclusion to on in your postgresql.conf and running my test
(which is attached to the
Anyway, I think this is worth fixing before release but it clearly isn't
worth attempting to rush a patch in the next few hours. I don't think
we'll find anyone who is happy with making it a restart-required option.
I couldn't find a patch/commit for this and was just wondering whether
someone
On Wed, Nov 12, 2008 at 09:46:09AM -0500, Robert Haas wrote:
The || operator is valid only if the dimensions
of the two arrays are equal (in which case it appends them) or if the
dimension of one of the arrays is one less than the other (in which
case, if legal, it treats the array of lesser
Thank you for your reviewing my code.
2008/11/12 Heikki Linnakangas [EMAIL PROTECTED]:
I've been slicing and dicing this patch for the last few days. There's a lot
of code in there, but here's some initial comments:
The code to initialize, advance, and finalize an aggregate should be shared
Robert Haas wrote:
Hmm, ISTM that cardinality() is implemented here in the manner
previously rejected for array_length()...
The objection was that basic functionality should not be implemented in
SQL. If we want to disallow all compatibility functions implemented in
SQL as well, we have
Robert Haas wrote:
It was pointed out to me today that a zero-dimensional matrix is a scalar.
This makes a bit of sense, if you say that
'{{56}}' is of type int[][], 2 dimensions
'{56}' is of type int[], 1 dimension
'56' is of type int, 0 dimensions
Notice that the number of brace pairs in
OK now that im using the right env var everything seems to work as
described. FYI I also tried to exercise the various new error paths
and everything seems good so as far as i'm concerned this looks good
to me. Ill go mark it as ready for commiter on the wiki. (whatever
that means you being a
Andrew Chernow [EMAIL PROTECTED] writes:
Just noticed that the last libpqtypes release was broken on windows when
dynamically linking. The problem is that windows has two addresses for
functions, the import library uses a stub ordinal address while the
DLL itself is using the real address;
Chuck McDevitt wrote:
What if the block of text is split in the middle of a multibyte character?
I don't think it is safe to assume raw blocks always end on a character
boundary.
Yeah, it's not. I realized myself after submitting. The generic approach
is to loop with pg_mblen() to find out
Tom Lane wrote:
Sergey Konoplev [EMAIL PROTECTED] writes:
You are right. I've found the odd thing (that completely drives me
mad) in postgresql.conf.
You are able to reproduce slow-not-in queries by switching
constraint_exclusion to on in your postgresql.conf and running my test
(which is
Hmm, ISTM that cardinality() is implemented here in the manner
previously rejected for array_length()...
...Robert
On Wed, Nov 12, 2008 at 8:13 AM, Peter Eisentraut [EMAIL PROTECTED] wrote:
Robert Haas wrote:
Updated version attached, this time without the compiler warning.
I have committed
Tom Lane wrote:
Robert Haas [EMAIL PROTECTED] writes:
Incidentally, I noticed while looking at this that \h with also
fails, even though WITH can now be the first word of a valid SQL
statement. I think we ought to patch psql to return the same help for
WITH as it does for SELECT.
Hmm. Given
Just noticed that the last libpqtypes release was broken on windows when
dynamically linking. The problem is that windows has two addresses for
functions, the import library uses a stub ordinal address while the
DLL itself is using the real address; yet another m$ annoyance. This
breaks
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Just noticed that the last libpqtypes release was broken on windows when
dynamically linking. The problem is that windows has two addresses for
functions, the import library uses a stub ordinal address while the
DLL itself is using the
On Wed, Nov 12, 2008 at 02:12:19PM +0200, Peter Eisentraut wrote:
Tom Lane wrote:
Seems like we ought to clean this up. I'm not sure which way to jump
though: should we decree that arrays of no elements must always have
zero dimensions, or should we get rid of that and standardize on, say,
I think it's actually more correct to say that {} has an undefined
number of dimensions.
That is your opinion, but not my argument above.
I'm aware of that. I believe that the semantics of array operations
should carry more weight than a count of curly braces, but certainly
you don't have to
Robert Haas wrote:
Updated version attached, this time without the compiler warning.
I have committed something based on this. The issue of empty arrays
will need a separate solution.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Richard Huxton [EMAIL PROTECTED] writes:
Tom Lane wrote:
Hmph. It's trying to see if the NOT IN condition is self-contradictory,
which of course it isn't, but the predicate_refuted_by machinery isn't
smart enough to determine that except by running through all N^2
combinations of the
TODO/issues
- add support of other data types to btree_gin
done, now btree_gin supports int2, int4, int8, float4, float8, money, oid,
timestamp, timestamptz, time, timetz, date, interval, macaddr, inet, cidr, text,
varchar, char, bytea, bit and varbit types
--
Teodor Sigaev
On Thu, Nov 13, 2008 at 4:52 AM, Tom Lane [EMAIL PROTECTED] wrote:
Yeah. An example of a closely related expression that it *would* be
able to prove self-contradictory is
WHERE x = ALL (ARRAY[1, 2, ...])
or perhaps slightly more realistically
WHERE x = ANY (ARRAY[1, 2, 3]) AND
Brendan Jurd [EMAIL PROTECTED] writes:
I guess my question is, what's the real benefit of going to all this
trouble trying to prove that clauses are false?
Not having to scan gigabytes of data in an excluded partition, for
instance.
Now the docs do say
Currently, constraint_exclusion
Brendan Jurd wrote:
On Thu, Nov 13, 2008 at 4:52 AM, Tom Lane [EMAIL PROTECTED] wrote:
Yeah. An example of a closely related expression that it *would* be
able to prove self-contradictory is
WHERE x = ALL (ARRAY[1, 2, ...])
or perhaps slightly more realistically
WHERE x = ANY
On Thu, Nov 13, 2008 at 5:16 AM, Tom Lane [EMAIL PROTECTED] wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
I guess my question is, what's the real benefit of going to all this
trouble trying to prove that clauses are false?
Not having to scan gigabytes of data in an excluded partition, for
I wrote:
We could respond to this in a number of ways:
1. Tough, don't do that.
2. Put some arbitrary limit on the number of subconditions in an AND or
OR clause before we give up and don't attempt to prove anything about
it.
3. Put in a narrow hack that will get us out of this specific
Hmm, I can get around the btree problem by not summing the special
space. This loses a bit of reliability because some of the most
critical bits of the page would not be protected by the CRC, but the
bulk of the data would be. And this allows me to get away from page
type specific tricks (like
On Tue, 2008-11-11 at 21:57 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2008-11-10 at 19:15 -0500, Tom Lane wrote:
The reason I was thinking about heap_lock_tuple is that it might provide
a suitable defense against that case.
OK. Lock tuple works OK, but its
Martijn van Oosterhout wrote:
If you're going to look at the line pointers anyway, couldn't you just
do it in one pass, like:
n = 0
next = tuple[n].hintbits
pos = 0
while pos BLOCK_SIZE:
if pos == next:
CRC_ADD( block[pos] mask )
n++
next = tuple[n].hintbits # If n
On Wed, Nov 12, 2008 at 11:08:13AM -0300, Alvaro Herrera wrote:
For this to work, we would have to create two (or more) versions of the
calculate checksum macro, one for heap pages and other for other pages.
I'm not sure how bad is that. The bit that's worse is that we'd need to
have external
Martijn van Oosterhout wrote:
On Wed, Nov 12, 2008 at 11:08:13AM -0300, Alvaro Herrera wrote:
However, your idea suggests something else that we could do to improve
the patch: skip the ItemId-lp_flags during the CRC calculation. This
would mean we wouldn't need to WAL-log those. The
Heikki Linnakangas [EMAIL PROTECTED] writes:
Which brings to mind an interesting customer case. They are running
queries like WHERE id IN (...), where ... is a *very* long list of
keys, against a table that's partitioned by ranges of id. The query was
running slow, because while constraint
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2008-11-11 at 21:57 -0500, Tom Lane wrote:
I was imagining that the heap_inplace_update operation would release the
lock. Is there some problem with the concept?
Not the concept, just the mechanism.
Current tuple lock requestors do
On Fri, 2008-11-07 at 16:52 -0500, Bruce Momjian wrote:
Simon, would you read the chapter on covert channels? You might
understand it better than I do and it might give you some ideas:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.5950
OK, read that now.
Looks to me
Alvaro Herrera [EMAIL PROTECTED] writes:
The other thing that maybe you didn't notice is that lp_flags are 2
bits, not a full byte. A byte-at-a-time CRC calculation is no help
there.
I think we're talking past each other. Martin and I are talking about doing
something like:
for (...)
...
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
Once this settles I suppose I should post a ECPG patch that's based
off of these Decode/Encode interval functions too?
Yeah, if you want. I think you'll find that the datetime code has
drifted far enough since ecpg forked it that you'll be
Tom Lane wrote:
Seems like we ought to clean this up. I'm not sure which way to jump
though: should we decree that arrays of no elements must always have
zero dimensions, or should we get rid of that and standardize on, say,
1-D array with lower bound 1 and upper bound 0?
It was pointed out
On Wed, 2008-11-12 at 16:25 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2008-11-11 at 21:57 -0500, Tom Lane wrote:
I was imagining that the heap_inplace_update operation would release the
lock. Is there some problem with the concept?
Not the concept, just the
I wrote:
2. Put some arbitrary limit on the number of subconditions in an AND or
OR clause before we give up and don't attempt to prove anything about
it.
So option #2 with a cutoff of 100 items or so is looking like the
best response.
I've applied a patch along this line to 8.2 and up, and
They're all barfing along this line:
dlltool --export-all --output-def libpg_trgmdll.def trgm_op.o trgm_gist.o
trgm_gin.o
dllwrap -o pg_trgm.dll --dllname pg_trgm.dll --def libpg_trgmdll.def
trgm_op.o trgm_gist.o trgm_gin.o -L../../src/backend -lpostgres
-L../../src/port -L/mingw/lib
Simon Riggs wrote:
The only remaining problem for me now is the size of the security
context column added to each row. I can accept a fixed length 4 byte
value, but anything longer just seems that it will render this unusable.
Normal apps should be able to benefit from row level security, as
Hello lists,
I am trying to run Slony on a Master Postgres 8.1.11 replicating to a
Slave same version and 2nd Slave Postgres 8.3.4.
The purpose is to update Postgres in production by steps, first slaves
then switchover to upgrade the master that will not be master when
upgraded.
I am
Hi, Pgsql-hackers.
what he's looking for is to somehow
use XML in lieu of, um, either SQL, PHP, libpq, or something like
that. (And the fact that those are 4 rather different things reveals
how confused the matter is.)
http://lists.xml.org/archives/xml-dev/200802/msg00213.html
Dmitry
On Wed, 2008-11-12 at 10:48 -0500, Jonah H. Harris wrote:
Anyway, I think this is worth fixing before release but it clearly isn't
worth attempting to rush a patch in the next few hours. I don't think
we'll find anyone who is happy with making it a restart-required option.
I couldn't
47 matches
Mail list logo
