Greg Smith írta:
On Thu, 19 Jun 2008, Zoltan Boszormenyi wrote:
This patch (revisited and ported to current CVS HEAD) is indeed using
Greg's original patch and also added another patch written by Mark Wong
that helps evicting closed XLOGs from memory faster.
Great, that will save me some
Greg Smith írta:
On Sun, 11 May 2008, Hans-Juergen Schoenig wrote:
we also made some simple autoconf hack to check for broken
posix_fadvise.
Because of how you did that, your patch is extremely difficult to even
test. You really should at least scan the output from diff you're
about to
Gregory Stark írta:
This is indeed really cool. I'm sorry I haven't gotten to doing what I
promised in this area but I'm glad it's happening anyways.
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
Can we get the rows in tree order, please?
...
After all, I didn't specify any ORDER
Yoshiyuki Asaba írta:
Hi,
From: Zoltan Boszormenyi [EMAIL PROTECTED]
Subject: Re: [PATCHES] WITH RECURSIVE patch V0.1
Date: Mon, 19 May 2008 08:19:17 +0200
Also, it seems there are no infinite recursion detection:
# with recursive x(level, parent, child) as (
select 1::integer, * from
Martijn van Oosterhout írta:
On Mon, May 19, 2008 at 08:19:17AM +0200, Zoltan Boszormenyi wrote:
The standard has a clause to specify depth-first order. However doing a
depth-first traversal would necessitate quite a different looking plan and
it's far less obvious (to me anyways) how to do
Martijn van Oosterhout írta:
On Mon, May 19, 2008 at 08:19:17AM +0200, Zoltan Boszormenyi wrote:
The standard has a clause to specify depth-first order. However doing a
depth-first traversal would necessitate quite a different looking plan and
it's far less obvious (to me anyways) how to do
Martijn van Oosterhout írta:
On Mon, May 19, 2008 at 11:56:17AM +0200, Zoltan Boszormenyi wrote:
From an implementation point of view, the only difference between
breadth-first and depth-first is that your tuplestore needs to be LIFO
instead of FIFO.
Are you sure? I think
Gregory Stark írta:
Martijn van Oosterhout [EMAIL PROTECTED] writes:
From an implementation point of view, the only difference between
breadth-first and depth-first is that your tuplestore needs to be LIFO
instead of FIFO.
I think it's not so simple. How do you reconcile that
David Fetter írta:
On Sun, May 18, 2008 at 08:51:29PM +0900, Tatsuo Ishii wrote:
WITH RECURSIVE patch V0.1
Here are patches to implement WITH RECURSIVE clause. There are some
limitiations and TODO items(see the Current limitations section
below). Comments are welcome.
1. Credit
These
Zoltan Boszormenyi írta:
Zoltan Boszormenyi írta:
Decibel! írta:
On Apr 3, 2008, at 12:52 AM, Zoltan Boszormenyi wrote:
Where is the info in the sequence to provide restarting with
the _original_ start value?
There isn't any. If you want the sequence to start at some magic
value, adjust
Gregory Stark írta:
Tom Lane [EMAIL PROTECTED] writes:
BTW, I trolled the contrib files for other v0 functions taking or
returning float4 or float8. I found seg_size (fixed it) and a whole
bunch of functions in earthdistance. Those use float8 not float4,
so they are not broken by this
Alvaro Herrera írta:
Tom Lane wrote:
Specifically, I think what you missed is that on some platforms C
functions pass or return float values differently from similar-sized
integer or pointer values (typically, the float values get passed in
floating-point registers).
Argh ... I would
Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
So I think we really do need to offer that compile-time option.
Failing to do so will be tantamount to desupporting v0 functions
altogether, which I don't think we're prepared to do.
I have asked the Cybertec guys for a patch
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
Both --enable and --disable-float4-byval produced only this regression,
but it seems to be a tuple order difference.
That looks suspiciously locale-ish; what locale are you running PG in?
regards, tom
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
That looks suspiciously locale-ish; what locale are you running PG in?
hu_HU.UTF-8
Ah, and I'll bet zs sorts after zy in hu_HU.
Yes, zs is a double letter that sorts after z in general un hu_HU.
The query
Zoltan Boszormenyi írta:
Decibel! írta:
On Apr 3, 2008, at 12:52 AM, Zoltan Boszormenyi wrote:
Where is the info in the sequence to provide restarting with
the _original_ start value?
There isn't any. If you want the sequence to start at some magic
value, adjust the minimum value.
There's
Hi,
I tried to split the previous patch up to see where the tsearch regression
comes from. So, it turned out that:
- float4 conversion is risk free (patch #1)
- float8 conversion is okay, too, if coupled with time[stamp[tz]] conversion
(patch #2) but with int64 timestamps enabled, the next
Tom Lane wrote:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
Gregory Stark írta:
1) Please don't include configure in your patch. I don't know why it's checked
into CVS but it is so that means manually removing it from any patch. It's
usually a huge portion of the diff so it's worth
Tom Lane wrote:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
Gregory Stark írta:
1) Please don't include configure in your patch. I don't know why it's checked
into CVS but it is so that means manually removing it from any patch. It's
usually a huge portion of the diff so it's worth
Alvaro Herrera írta:
I don't think
my $int64passbyval = (?($real64 = 1)t|f);
works. Perhaps
my $int64passbyval = $real64 ? 't' : 'f';
Thanks. Modified patch attached.
Stupid question follows. Now that float4 is passed by value
unconditionally, is it worth modifying the
for that.
Comments welcome.
Best regards,
Zoltán Böszörményi
Zoltan Boszormenyi írta:
Hi,
I am working on this TODO item:
* Consider allowing 64-bit integers and floats to be passed by value on
64-bit platforms
Also change 32-bit floats (float4) to be passed by value at the same
time
Hi,
Gregory Stark írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
- the int8inc(), int2_sum() and int4_sum() used pointers directly from the
Datums
for performance, that code path is now commented out, the other code path
is correct for the AggState and !AggState runs and correct
Gregory Stark írta:
Ok, ignore my previous message. I've read the patch now and that's not an
issue. The old code path is not commented out, it's #ifdef'd conditionally on
HAVE_LONG_INT_64 is right (well it seems right, it's a bit hard to tell in
patch form).
A few comments:
1) Please don't
Zoltan Boszormenyi írta:
Gregory Stark írta:
4) Your problems with tsearch and timestamp etc raise an interesting
problem.
We don't need to mark this in pg_control because it's a purely a
run-time
issue and doesn't affect on-disk storage. However it does affect ABI
compatibility
Zoltan Boszormenyi írta:
BTW I found the tsearch bug, it was a missing conversion of float4
in gistproc.c, it was an unfortunate detail that this didn't cause a
segfault,
it woul have been easier to find. Now there are no failing regression
tests.
Disregards this patch, the bugfix
Gregory Stark írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
Zoltan Boszormenyi írta:
Gregory Stark írta:
4) Your problems with tsearch and timestamp etc raise an interesting
problem.
We don't need to mark this in pg_control because it's a purely a run-time
issue
Hi,
attached is our patch against HEAD which enables extending CommandIds
to 64-bit. This is for enabling long transactions that really do that much
non-read-only work in one transaction.
The feature is off by default, you need to --enable-huge-commandid.
It fails only one regression test
Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
attached is our patch against HEAD which enables extending CommandIds
to 64-bit. This is for enabling long transactions that really do that much
non-read-only work in one transaction.
I think you should add a pg_control field
Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
attached is our patch against HEAD which enables extending CommandIds
to 64-bit. This is for enabling long transactions that really do that much
non-read-only work in one transaction.
I think you should add a pg_control field
Hi,
Pavel Stehule írta:
On 29/01/2008, Peter Eisentraut [EMAIL PROTECTED] wrote:
Am Montag, 28. Januar 2008 schrieb Pavel Stehule:
this patch define new function flag - OBFUSCATE. With this flag
encrypted source code is stored to probin column. Password is stored
in GUC_SUPERUSER_ONLY
Hi,
we came across a problem when you want to dump only one schema.
The ASCII output when loaded with psql into an empty database
doesn't produce an identical schema to the original.
The problem comes from this statement ordering:
SET ... -- some initial DB parameters
...
SET search_path =
Hi,
Pavan Deolasee írta:
On 9/18/07, *Jaime Casanova* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
this sql scripts make current cvs + patch to crash with this message
in the logs:
Can you please check if the attached patch fixes the issue for you ?
It sets t_tableOid
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
Or not, it's just a bitter and late (because of my bitterness) response
to the rejection of my IDENTITY/GENERATED patches.
Where's the much praised standard behaviour on standard syntax?
So much for hypocrisy.
Hm? There's
Hi,
here's a fix for a _very_ longstanding bug in PostgreSQL.
According to SQL:2003 DEFAULT may only contain
certain functional expressions and constant literals.
Please, note the year of the standard. Or I know a better one,
PostgreSQL is not even SQL92 compliant in this regard, after 14
Hi,
here's the patch with the modifications suggested by Tom Lane.
The postfix rule was deleted from b_expr and the reverse parsing
in ruleutils.c::get_oper_expr() always puts parentheses around
postfix operators.
Other changes:
- OVERRIDING SYSTEM VALUE in COPY can appear
at any place in the
And here it is attached. Sorry.
Zoltan Boszormenyi írta:
Hi,
here's the patch with the modifications suggested by Tom Lane.
The postfix rule was deleted from b_expr and the reverse parsing
in ruleutils.c::get_oper_expr() always puts parentheses around
postfix operators.
Other changes
can't be created with a type that
cannot be cast from bigint i.e. box. I added it to the test case.
Please, review.
Best regards,
Zoltán Böszörményi
Zoltan Boszormenyi írta:
And here it is attached. Sorry.
Zoltan Boszormenyi írta:
Hi,
here's the patch with the modifications suggested by Tom Lane
Tom Lane írta:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
So I think attaching a precedence to the GENERATED keyword is dangerous.
Especially when we have a good workaround which would just require use
of () around certain postfix-operator expressions.
Andrew Dunstan írta:
Zoltan Boszormenyi wrote:
On the other hand, marking GENERATED as %right
solves this issue. I hope it's an acceptable solution.
If anything I should have thought it would be marked %nonassoc.
cheers
andrew
That works, too.
Best regards,
Zoltán Böszörményi
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
Andrew Dunstan írta:
Zoltan Boszormenyi wrote:
On the other hand, marking GENERATED as %right
solves this issue. I hope it's an acceptable solution.
If anything I should have thought it would be marked
Tom Lane írta:
Andrew Dunstan [EMAIL PROTECTED] writes:
Zoltan Boszormenyi wrote:
Thanks. This idea solved one of the two shift/reduce conflicts.
But the other one can only be solved if I put GENERATED
into the reserved_keyword set. But the standard spec says
it's unreserved. Now what
Zoltan Boszormenyi írta:
Tom Lane írta:
Andrew Dunstan [EMAIL PROTECTED] writes:
Zoltan Boszormenyi wrote:
Thanks. This idea solved one of the two shift/reduce conflicts.
But the other one can only be solved if I put GENERATED
into the reserved_keyword set. But the standard spec says
Zoltan Boszormenyi írta:
Andrew Dunstan írta:
Florian G. Pflug wrote:
bison -y -d gram.y
conflicts: 2 shift/reduce
I'ts been quite a time since I last used bison, but as far as I
remember, you can tell it to write a rather details log about
it's analysis of the grammar. That log should
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
So, I should allow DROP DEFAULT, implement
SET DEFAULT GENERATED ALWAYS AS
and modify the catalog so the GENERATED property
is part of pg_attrdef.
Sounds good.
Finally here it is.
What about IDENTITY?
Should it also
Zoltan Boszormenyi írta:
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
So, I should allow DROP DEFAULT, implement
SET DEFAULT GENERATED ALWAYS AS
and modify the catalog so the GENERATED property
is part of pg_attrdef.
Sounds good.
Finally here it is.
What about
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
[ IDENTITY/GENERATED patch ]
I got around to reviewing this today.
Thanks for the review.
Sorry for the bit late reply, I was ill and
then occupied with some other work.
- unique index checks are done in two steps
Andrew Dunstan írta:
Zoltan Boszormenyi wrote:
Tom Lane írta:
- unique index checks are done in two steps
to avoid inflating the sequence if a unique index check
is failed that doesn't reference the IDENTITY column
This is just not acceptable --- there is nothing in the standard
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
The idea wouldn't have considered to cross my mind
if Tom didn't mention the action-at-a-distance behaviour.
AFAIR, that remark had to do with NEXT VALUE FOR, which SQL2003 defines
in a very weird way (it's not equivalent
Tom Lane írta:
I wrote:
I see another problem with this patch: the code added to
ATExecDropColumn is a crude hack. It doesn't work anyway since this is
not the only possible way for columns to be dropped (another one that
comes to mind immediately is DROP TYPE ... CASCADE). The only
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
Before you get too excited about making generated columns disappear
automatically in all these cases, consider that dropping a column
is not something to be done lightly --- it might contain irreplaceable
data
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
I have two questions about the dependency system.
1. Is there a built-in defense to avoid circular dependencies?
It doesn't have a problem with them, if that's what you mean.
2. If I register dependencies
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
So, I should allow DROP DEFAULT, implement
SET DEFAULT GENERATED ALWAYS AS
and modify the catalog so the GENERATED property
is part of pg_attrdef.
Sounds good.
What about IDENTITY?
Should it also be part of pg_attrdef
to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Zoltan Boszormenyi wrote:
Hi,
I think
Hi,
I think now this is really the final version.
Changes in this version is:
- when dropping a column that's referenced
by a GENERATED column, the GENERATED
column has to be also dropped. It's required by SQL:2003.
- COPY table FROM works correctly with IDENTITY
and GENERATED columns
-
Resending compressed, it seems pgsql-patches
doesn't let me post so large patches.
Zoltan Boszormenyi írta:
Hi,
I have finished my GENERATED/IDENTITY patch
and now it does everything I wanted it to do. Changes
from the previous version:
- GENERATED columns work now
- extended testcase to test
Hi,
here comes the next version. Changes:
* Implemented ALTER TABLE ... DROP IDENTITY
and SET GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY
* Extended documentation and testcase for the above.
* pg_dump now dumps the proper ALTER for such columns.
Reintroduced the pg_dump feature to dump
Hi,
I started working on my previous patch, encouraged
by the fact that it became a wishlist item for 8.3. :-)
The changes in this version are:
- Refreshed to almost current (5 days old)
CVS version of 8.3 devel
- The original SERIAL pseudo type is left alone,
you _have to_ spell out
Thanks!!!
Tom Lane írta:
=?iso-8859-2?Q?B=F6sz=F6rm=E9nyi_Zolt=E1n?= [EMAIL PROTECTED] writes:
as per your suggestion, the COPY view TO support was cut and
a hint was added. Please, review.
Committed after some refactoring to avoid code duplication.
Unfortunately, in a moment of
Bruce Momjian írta:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Zoltan Boszormenyi wrote:
My v8 had the syntax support for
COPY (SELECT ...) (col1, col2, ...) TO
and it was actually working. In your v9
you rewrote the syntax parsing so that
feature was lost
Andrew Dunstan írta:
Alvaro Herrera wrote:
Böszörményi Zoltán wrote:
Hi,
what's the problem with COPY view TO, other than you don't like it? :-)
The problem is that it required a ugly piece of code. Not supporting it
means we can keep the code nice. The previous discussion led to
Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
Andrew Dunstan írta:
Alvaro Herrera wrote:
Böszörményi Zoltán wrote:
what's the problem with COPY view TO, other than you don't like it? :-)
The problem is that it required a ugly piece of code
Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
Alvaro Herrera írta:
Remember that we were talking about supporting views, not tables. And
if a view uses a slow query then you are in immediate danger of having a
slow COPY. This may not be a problem but it needs to be discussed
Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
Alvaro Herrera írta:
But COPY view (col1, col2, ...) TO may still be
useful even if the COPY (SELECT ...) (col1, col2, ...) TO
is pointless. [1]
Hum, I don't understand what you're saying here -- are you saying that
you can't
Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
Alvaro Herrera írta:
But COPY view (col1, col2, ...) TO may still be
useful even if the COPY (SELECT ...) (col1, col2, ...) TO
is pointless. [1]
Hum
Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
I think at this point is someone else's judgement whether you can put it
back or not. Tom already said that he doesn't object to the feature per
se; no one else seems opposed to the feature per se, in fact.
Now, I don't really see _how_ to do
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
Alvaro Herrera írta:
Hum, are you going to put back the original cruft to support copy view?
I suggest you don't do that.
Well, the other way around is to teach heap_open()
to use views. Brrr. Would it be any
Bruce Momjian írta:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
Thanks. Would you please add this instead?
psql
Yes, I am not ready with it.
Bruce Momjian írta:
This is being done for 8.3, right?
---
Zoltan Boszormenyi wrote:
Hi,
here's the next version. Changes:
- Extended documentation
- Extending permissions to new
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
How about the callback solution for the SELECT case
that was copied from the original? Should I consider
open-coding in copy.c what ExecutorRun() does
to avoid the callback?
Adding a DestReceiver type is a good solution
Zoltan Boszormenyi írta:
The option parsing and error checking is now common.
I also changed it to use transformStmt() in analyze.c.
However, both the UNION and sunselect cases give me
something like this:
ERROR: could not open relation 1663/16384/16723: No such file or
directory
What else
Zoltan Boszormenyi írta:
Zoltan Boszormenyi írta:
The option parsing and error checking is now common.
I also changed it to use transformStmt() in analyze.c.
However, both the UNION and sunselect cases give me
something like this:
ERROR: could not open relation 1663/16384/16723: No such file
Hi,
Bruce Momjian írta:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
I think Alvaro is saying we need it in a few days, not longer.
I thought he was saying today ;-)
He actually said now, but I don't
Zoltan Boszormenyi írta:
Hi,
Bruce Momjian írta:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
I think Alvaro is saying we need it in a few days, not longer.
I thought he was saying today ;-)
He actually said
Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
OK, here's my current version. The reference leak is fixed.
But as my testcase shows, it only works for single selects
currently. The parser accepts it but COPY doesn't produce
the expected output. Please, suggest a solution.
I'm
Hi,
here's the next version. Changes:
- Extended documentation
- Extending permissions to new sequences
ALTER TABLE tab ADD col type GENERATED AS IDENTITY
didn't work as advertised, now it seems to.
- Test case was also extended.
- Previously introduced memory leaks were plugged. Really.
Now
Hi,
here's the next, changes are at the end.
Zoltan Boszormenyi írta:
Hi,
my last patch didn't make it to the -hackers list,
here's a newer one. Let me list what this patch does now:
- CREATE TABLE/ALTER TABLE ADD syntax support for
GENERATED { ALWAYS | BY DEFAULT } AS
{ ( expr
Hi,
my last patch didn't make it to the -hackers list,
here's a newer one. Let me list what this patch does now:
- CREATE TABLE/ALTER TABLE ADD syntax support for
GENERATED { ALWAYS | BY DEFAULT } AS
{ ( expr ) | IDENTITY ( seq_opts ) }
- catalog indicators of the above
77 matches
Mail list logo
