Re: [PATCHES] posix advises ...

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 fast

Re: [PATCHES] posix advises ...

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 > ab

Re: [PATCHES] [HACKERS] WITH RECURSIVE patch V0.1

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 con

Re: [PATCHES] [HACKERS] WITH RECURSIVE patch V0.1

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 thin

Re: [PATCHES] [HACKERS] WITH RECURSIVE patch V0.1

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

Re: [PATCHES] [HACKERS] WITH RECURSIVE patch V0.1

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

Re: [PATCHES] WITH RECURSIVE patch V0.1

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::i

Re: [PATCHES] WITH RECURSIVE patch V0.1

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? ... Afte

Re: [PATCHES] WITH RECURSIVE patch V0.1

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 pat

Re: [PATCHES] [HACKERS] TRUNCATE TABLE with IDENTITY

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, a

Re: [PATCHES] float4/float8/int64 passed by value with tsearchfixup

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

Re: [PATCHES] float4/float8/int64 passed by value with tsearch fixup

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&q

Re: [PATCHES] float4/float8/int64 passed by value with tsearch fixup

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? r

Re: [PATCHES] float4/float8/int64 passed by value with tsearch fixup

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 f

Re: [PATCHES] float4/float8/int64 passed by value with tsearch fixup

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

Re: [PATCHES] [HACKERS] TRUNCATE TABLE with IDENTITY

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. Th

[PATCHES] float4/float8/int64 passed by value with tsearch fixup

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 on

Re: [PATCHES] Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1

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

Re: [PATCHES] Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1

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

Re: [PATCHES] Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1

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

Re: [PATCHES] Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1

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

Re: [PATCHES] int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1

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 bugfi

Re: [PATCHES] Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1

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 com

[PATCHES] Re: int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1

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 inc

Re: [PATCHES] int8/float8/time/timestamp[tz]/float4 passed by value, was Re: Fix HAVE_LONG[_LONG]_INT_64 to really define to 1

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

int8/float8/time/timestamp[tz]/float4 passed by value, was Re: [PATCHES] Fix HAVE_LONG[_LONG]_INT_64 to really define to 1

me in the near future 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 valu

[PATCHES] Fix HAVE_LONG[_LONG]_INT_64 to really define to 1

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. For genbki.sh, to correctly determine whether HAVE_LONG_INT_64 is defined, the attached bug

Re: [PATCHES] 64-bit CommandIds

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 and

Re: [PATCHES] 64-bit CommandIds

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 and

[PATCHES] 64-bit CommandIds

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 (witho

Re: [PATCHES] WIP: plpgsql source code obfuscation

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_ONL

[PATCHES] Problem with pg_dump -n schemaname

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 = schem

Re: [PATCHES] HOT version 18

Hi, Pavan Deolasee írta: On 9/18/07, *Jaime Casanova* <[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 b

Re: [PATCHES] Standard compliant DEFAULT clause

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.

[PATCHES] Standard compliant DEFAULT clause

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 years!

Re: [PATCHES] [HACKERS] Behavior of GENERATED columns per SQL2003

Forwarded to -patches because of the attachment. Eredeti üzenet Tárgy: Re: [HACKERS] Behavior of GENERATED columns per SQL2003 Dátum: Tue, 08 May 2007 12:38:32 +0200 Feladó: Zoltan Boszormenyi <[EMAIL PROTECTED]> Címzett:Tom Lane <[EMAIL PROTE

Re: [PATCHES] HOT patches

Hi, Pavan Deolasee írta: Hi All, Please see the set of HOT patches, broken down as suggested by the community members for easy review. There are 5 patches, they should apply cleanly on current CVS HEAD, but have dependencies. So one must apply patch1 before applying patch2 and so on. At each s

Re: [PATCHES] New version of GENERATED/IDENTITY, was Re: parser dilemma

st 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, some last changes. Really. :-) I made

Re: [PATCHES] New version of GENERATED/IDENTITY, was Re: parser dilemma

olumn 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 sugges

Re: [PATCHES] New version of GENERATED/IDENTITY, was Re: parser dilemma

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 ch

[PATCHES] New version of GENERATED/IDENTITY, was Re: parser dilemma

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

Re: [PATCHES] [HACKERS] parser dilemma

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.

Re: [PATCHES] [HACKERS] parser dilemma

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 woul

Re: [PATCHES] [HACKERS] parser dilemma

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ör

Re: [PATCHES] [HACKERS] parser dilemma

Zoltan Boszormenyi írta: Martijn van Oosterhout írta: On Thu, Apr 19, 2007 at 11:19:40AM +0200, Zoltan Boszormenyi wrote: The problem comes from cases like colname coltype DEFAULT 5! GENERATED ... Since b_expr allows postfix operators, it takes one more token of lookahead than we have

Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

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 spe

Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

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 unre

Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

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

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

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

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

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 i

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

Tom Lane írta: Zoltan Boszormenyi <[EMAIL PROTECTED]> writes: Tom Lane írta: The latter would treat GENERATED BY DEFAULT AS IDENTITY the same as SERIAL. Is there any good reason to distinguish the two? Yes. Plain SERIALs can be updated with given

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

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_a

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

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 regis

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

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.

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

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 correct

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

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&

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

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 sta

Re: IDENTITY/GENERATED v36 Re: [PATCHES] Final version of IDENTITY/GENERATED patch

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

Re: [PATCHES] Final version of IDENTITY/GENERATED patch

ded 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

Re: [PATCHES] Final version of IDENTITY/GENERATED patch

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 - ext

Re: [PATCHES] Final version of IDENTITY/GENERATED patch

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

[PATCHES] IDENTITY/GENERATED v31

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 OVE

[PATCHES] New version of IDENTITY/GENERATED

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 GENERATED

Re: [PATCHES] [HACKERS] Performance testing of COPY (SELECT) TO

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 pu

Re: [PATCHES] [HACKERS] Performance testing of COPY (SELECT)

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 featu

Re: [PATCHES] [HACKERS] Performance testing of COPY (SELECT) TO

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. Woul

Re: [PATCHES] [HACKERS] Performance testing of COPY (SELECT) TO

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

Re: [PATCHES] [HACKERS] Performance testing of COPY (SELECT) TO

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

Re: [PATCHES] [HACKERS] Performance testing of COPY (SELECT) TO

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

Re: [PATCHES] [HACKERS] Performance testing of COPY (SELECT) TO

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

Re: [PATCHES] [HACKERS] Performance testing of COPY (SELECT) 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

Re: [PATCHES] [HACKERS] Performance testing of COPY (SELECT) TO

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 th

Re: [PATCHES] [HACKERS] Performance testing of COPY (SELECT) TO

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 built-i

Re: [PATCHES] IDENTITY/GENERATED columns

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 t

Re: [HACKERS] [PATCHES] COPY view

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

Re: [HACKERS] [PATCHES] COPY view

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

Re: [HACKERS] [PATCHES] COPY view

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 so

Re: [HACKERS] [PATCHES] COPY view

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.

Re: [HACKERS] [PATCHES] COPY view

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

Re: [HACKERS] [PATCHES] COPY view

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 thi

Re: [PATCHES] IDENTITY/GENERATED columns

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

Re: [PATCHES] IDENTITY/GENERATED columns

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 } A

[PATCHES] IDENTITY/GENERATED columns

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 properti