Tom Lane schrieb:
Bruce Momjian pgman@candle.pha.pa.us writes:
It seems like a cool feature.
The fundamental problem with it is that plpgsql isn't designed to deal
with dynamically changing data types. The patch as submitted contained
some hacks that sort of dealt with this in some cases (I
Patch applied. Thanks.
---
[EMAIL PROTECTED] wrote:
Bruce Momjian schrieb:
This patch cannot be applied. 'active_simple_exprs' is referenced but
not defined. I think the new variable name is 'simple_eval_estate',
Bruce Momjian pgman@candle.pha.pa.us writes:
Patch applied. Thanks.
I wish to object to this patch; it's poorly designed, poorly coded, and
badly documented. The philosophy seems to be I want this feature
and I don't care what I have to do to the semantics and performance
of plpgsql to get it.
OK, patch reverted, and attached. Would the author please revise?
Thanks.
It seems like a cool feature.
---
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Patch applied. Thanks.
I wish to object to
Bruce Momjian pgman@candle.pha.pa.us writes:
It seems like a cool feature.
The fundamental problem with it is that plpgsql isn't designed to deal
with dynamically changing data types. The patch as submitted contained
some hacks that sort of dealt with this in some cases (I don't think it
[EMAIL PROTECTED] said:
The patch was now hanging around more than 9 months,
and it was already accepted during the
original discussion by Neil Conway.
Nonsense. I provided some specific code cleanup suggestions and said that
I didn't object to the general feature. That should not be taken as
No, the author would not.
Tom did participate in the discussion at the time
when the original patch was developed.
The patch was now hanging around more than 9 months,
and it was already accepted during the
original discussion by Neil Conway. Please figure out
by yourselves who might be the one
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list
It was agreed earlier that this should be saved for 8.2, I believe.
-Neil
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Titus von Boxberg wrote:
Tom Lane schrieb:
Titus von Boxberg [EMAIL PROTECTED] writes:
It works for me if we
-Ursprüngliche Nachricht-
Von: Tom Lane
An: Neil Conway
Cc: Titus von Boxberg
Betreff: Re: [PATCHES] PL/PGSQL: Dynamic Record Introspection
---
There's a worse objection, which is that % is a perfectly valid operator
OK. I did not recognize that.
Another small
Titus von Boxberg [EMAIL PROTECTED] writes:
Questions:
- could anyone who knows Oracle better than me confirm
that with Oracle there are no RECORD variables of varying
dynamically assigned type?
Anyone?
- is the syntax RECORD.(identifier), RECORD.(*), RECORD.(#)
still acceptable?
It
On 7/19/05 8:11 AM, Titus von Boxberg [EMAIL PROTECTED] wrote:
As for NFIELDS, I don't think we need it -- you can always measure the
length of the FIELDNAMES array.
I would like to leave it there. As far as I can see it's much faster
than other builtins for evaluating array dimensions and I
Neil Conway [EMAIL PROTECTED] writes:
Titus von Boxberg wrote:
What do you mean by right syntax. There are hundreds of examples
in programming languages where a small syntactic difference leads to
totally different semantics.
Well, I'm just not happy that foo.bar means something completely
Titus von Boxberg wrote:
What do you mean by right syntax. There are hundreds of examples
in programming languages where a small syntactic difference leads to
totally different semantics.
Well, I'm just not happy that foo.bar means something completely
different than foo%bar -- foo%bar isn't
Neil Conway [EMAIL PROTECTED] writes:
Not from me. You missed the 8.1 freeze by about two weeks, so I'm not
sure if this is a candidate for 8.1 though.
Not a chance.
regards, tom lane
---(end of broadcast)---
TIP 3: Have
-Ursprüngliche Nachricht-
Von: Tom Lane [mailto:[EMAIL PROTECTED]
Neil Conway [EMAIL PROTECTED] writes:
Not from me. You missed the 8.1 freeze by about two weeks, so I'm not
sure if this is a candidate for 8.1 though.
Not a chance.
regards, tom lane
I'd
Titus von Boxberg wrote:
Having read the FAQ, it's not clear to me, where the patches go (and when)
that I would send into this list.
These are my open questions:
Are the patches applied to HEAD?
It depends on the patch. New features are almost exclusively only
applied to HEAD, whereas
Titus von Boxberg wrote:
With the following patch it's possible to
- extract all field names of a record into an array
- extract field count of a record
- address a single field of a record with a variable
containing the field name (additional to the usual record.fieldname
notation where the
good idea. it's what can eliminate not neccessery using plperl. I would to
see it in plpgsql.
regards
Pavel
On Thu, 14 Jul 2005, Titus von Boxberg wrote:
Hi all,
I needed introspection capabilities for record types to write more generic
trigger procedures in PL/PGSQL.
With the
Neil Conway schrieb:
Titus von Boxberg wrote:
Can you supply some proper regression tests, please? i.e. patch sql/plpgsql.sql and
expected/plpgsql.out in src/test/regress
In sql/plpgsql.sql I have added a function testing the new features
and altered expected/plpgsql.out
A few minor
Neil Conway schrieb:
Titus von Boxberg wrote:
Can you supply some proper regression tests, please? i.e. patch
sql/plpgsql.sql and expected/plpgsql.out in src/test/regress
In sql/plpgsql.sql I have added a function testing the new features
and altered expected/plpgsql.out
A few minor
Neil Conway schrieb:
I wonder if this is the right syntax. record%identifier is doing
something fundamentally different from record.identifier, but the syntax
doesn't make that clear. I don't have any concrete suggestions for
improvement, mind you... :)
What do you mean by right syntax. There
Hi all,
I needed introspection capabilities for record types to write more generic
trigger procedures in PL/PGSQL.
With the following patch it's possible to
- extract all field names of a record into an array
- extract field count of a record
- address a single field of a record with a variable
23 matches
Mail list logo
