Is there any way, short of using a debugger with a strategically placed
breakpoint, to tell if a SQL function has been inlined?
Joe
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
Bruce Momjian wrote:
http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-7-4
I need people to check this and help me with the items marked 'bjm'. I
am confused about the proper text for those sections.
Allow polymorphic SQL functions (Joe)
bjm ??
What isn't clear about this?
Bruce Momjian wrote:
What had me really confused was the first release item:
Allow polymorphic SQL functions (Joe)
How does an SQL function query the data types passed to it? Once I
saw that I thought I didn't underestand what polymorphic functions
were.
It doesn't need to. For example:
CREATE
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I think we should fix it but not force an initdb ---
information_schema is new and I am not sure how many people are using
it.
Yeah, I'm leaning that way too. We could publicize a script to fix the
problem in any beta5 or RC1 databases that
Hannu Krosing wrote:
Ryan Mahoney kirjutas N, 06.11.2003 kell 23:03:
I am running PostgreSQL 7.3.1 on i686-pc-linux-gnu, compiled by GCC 2.96
what does just
SELECT replace(data, '\'', '\'\'')
FROM temp_sales_lead
ORDER BY id, row LIMIT 10;
produce ?
There was a bug in replace(), fixed by Tom
Bruce Momjian wrote:
Having another process do the writing does allow some paralellism, but
people don't seem to care of buffers having to be read in from the
kernel buffer cache, so what big benefit do we get by having someone
else write into the kernel buffer cache, except allowing a central
Bruce Momjian wrote:
Agreed, we can't resize shared memory, but I don't think most OS's swap
out shared memory, and even if they do, they usually have a kernel
configuration parameter to lock it into kernel memory. All the old
unixes locked the shared memory into kernel address space and in fact
Tom Lane wrote:
Joe, do you recall the reasoning for this code in parse_coerce.c?
if (targetTypeId == ANYOID ||
targetTypeId == ANYARRAYOID ||
targetTypeId == ANYELEMENTOID)
{
/* assume can_coerce_type verified that implicit coercion is okay */
/* NB: we do
Jan Wieck wrote:
http://developer.postgresql.org/~wieck/slony1.html
Very interesting read. Nice work!
We want to build this system as a community project. The plan was from
the beginning to release the product under the BSD license. And we think
it is best to start it as such and to ask for
Jan Wieck wrote:
If you mean to configure the system to replicate rows to different
destinations (slaves) based on arbitrary qualifications, no. I had
thought about it, but it does not really fit into the datacenter and
failover picture, so it is not required to meet the goals and adds
I just noticed tonight that the new initdb introduced a subtle change of
behavior. I use a shell script to automate the process of
- rm old data directory
- mkdir new data directory
- initdb
- load from pgdumpall
Now, that second step is not needed, but as of today it produces an
installation
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
Now, that second step is not needed, but as of today it produces an
installation that won't start due to improper permissions on data
That's a bug --- evidently the fix permissions path of control is
wrong; can you take a look?
Here's a small
Marc G. Fournier wrote:
On Fri, 14 Nov 2003, Andrew Dunstan wrote:
I'm confused. My understanding from what Tom said is that it affects all
configurations.
the stats collector problem, from what I've seen through this list,
affects Solaris, and only some Solaris configuration ..
But the issue at
Tom Lane wrote:
The pgstat patch has already been checked to my satisfaction, but the
datetime patch needs more eyeballs on it; anyone out there have time to
look at it?
FWIW, it looks good to me, seems to work as intended, and passes all
existing regression tests.
Joe
Christopher Kings-Lynne wrote:
I made up a more thorough regression test for date input formats, and
found that there were still some cases that were rejected :-(. Attached
is a more complete patch that handles all month-name cases, and
explicitly can not change the behavior when there's not a
Peter Eisentraut wrote:
Christopher Kings-Lynne writes:
I'm just interested in what everyone's personal plans for 7.5
development are?
There are still some low-hanging fruit and some
below-the-cloudy-sky-hanging fruit in there, for instance
[...snip...]
Basic array support
^^^
As of this change:
http://archives.postgresql.org/pgsql-committers/2003-11/msg00278.php
I can't seem to configure --with-krb5.
The configure script I've used (derived from what the the RH9 RPM spec
file does) for quite some time now is:
./configure \
--host=i386-redhat-linux \
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
As of this change:
http://archives.postgresql.org/pgsql-committers/2003-11/msg00278.php
I can't seem to configure --with-krb5.
I believe the idea is that instead of
--with-krb5=/usr/kerberos
you now need
--with-krb5 --with-includes=/usr
Tom Lane wrote:
This failure is actually entirely pointless, because (AFAIK) any page
that is brought in during WAL recovery is going to be overwritten in
toto from the WAL log. So it would be safe to run WAL recovery with
zero_damaged_pages enabled. Rather than expecting DBAs to think of that
Bruce Momjian wrote:
I have loaded the patch queue with all patches that were in my main
mailbox:
http://momjian.postgresql.org/cgi-bin/pgpatches
I posted an alternative to this one
http://candle.pha.pa.us/mhonarc/patches/msg4.html
for comment last night (however I can't find it in the
Tom Lane wrote:
Yes. Please commit to 7.3 branch before Tuesday noon so it gets into
7.3.5 (or if you can't make that, let me know and we'll work something
out).
Done.
Joe
---(end of broadcast)---
TIP 7: don't forget to increase your free space
We (mostly Bruce, Tom, Peter, and I) have been having a discussion on
the PATCHES list regarding some new functionality related to read-only
GUC variables. The net result is pasted at the bottom of this post. Here
is a link to the discussion:
Bruce Momjian wrote:
Marc G. Fournier wrote:
I'd go with block_size ...
True, page size usually references virtual memory pages, so it is
related to virtual memory mapping. Block size is much more related to
on-disk storage, true. The only reason I was leaning toward page is
that it is possible
you never read my reply to you all the way to the bottom. I said:
Joe Conway wrote:
Alvar Freude wrote:
select * from test where b like '\001%';
This is weird. I'm sure it worked at one time -- will research.
Joe
I'm actively working on your issue. Please quit spamming all the lists
Alvar Freude wrote:
I'm sorry, but after reading the desciption of bugs again I realised that
according to the list desciption bugs is the wrong one und hackers the
right; so, after debugging my code two days I'm now sure that there is
something wrong with Postgres. Normally such Problems are in
Marc G. Fournier wrote:
To accomodate ppls travel scheduales, we are going to move the 7.4.1
release up to Monday, *unless* there is a report before then about
something that needs to be fixed first ... we know of nothing outstanding
right now ...
This means it will be tag'd/bundled on Sunday ...
Josh Berkus wrote:
max_function_args - int
Shows the maximum number of function arguments
max_index_keys - int
Shows the maximum number of index keys
Have we decoupled these two variables? Last I checked, their values still
had to be identical. If they have not been decoupled and won't
Alvar Freude wrote:
while changing a column from base255 encoded text (all except null byte) to
bytea, I found the following bug in Postgresql's LIKE operator with indexes
(it follows a more detailed description then my old mails in -bugs and
- -general, including the proof of the bug):
Please try
Alvar Freude wrote:
has this about one week time? I travel on monday to Geneva (World Summit on
the Information Society) and have a lot to prepare ... :-(
I'll make a report when I have some minutes (or hours ;) ) ...
Well, 7.4.1 will be bundled up for release on Sunday, so it would be
ideal to
Marc G. Fournier wrote:
On Sat, 6 Dec 2003, Peter Eisentraut wrote:
I suppose not, but it's being worked on.
Is that the one that Joe just mentioned workign on? about BYTEA?
I don't think so.
Joe
---(end of broadcast)---
TIP 1: subscribe and
Alvaro Herrera wrote:
Me too. I've created many functions to extract data that are joined to
other functions. All in all the result is not as optimal as it could
be, because the optimizer can not poke into the functions, and the
estimates about functions are only guesses. If one could use
Christopher Kings-Lynne wrote:
/usr/include/openssl/asn1.h:907: syntax error before `)'
In file included from /usr/include/openssl/evp.h:145,
from /usr/include/openssl/x509.h:67,
from /usr/include/openssl/ssl.h:177,
from
David Fetter wrote:
I've come up with yet another little hack, this time for turning 1-d
arrays into CSV format.
You mean like this (which is new in 7.4)?
regression=# select array_to_string (array[1,2,3], ',');
array_to_string
-
1,2,3
(1 row)
See:
Robert Bedell wrote:
I'm curious if anyone has ever looked into adding OLAP functionality (per
the SQL99 specs) into PostGreSQL. I don't actually own the proper SQL99
specifications, and since the newer sql2003 ones are coming out I don't know
which to purchase. Could someone point me in the
A E wrote:
I am attempting to use Setof Record dynamically. I am developing an
application where I will not know what the end-user is trying to work
with from a web front end. Thus I will not know before hand the
structure of the table I am trying to pull the record from.
[code]
I know that I
Tom Lane wrote:
Reverting the change will bring back the bug for which it was created.
It does seem though that we have an inadequate model of how to perform
permission checks. In particular, the write flag bit in RTEs is
context dependent: it can mean insert, update, or delete permission
Tom Lane wrote:
This is exactly what I'm talking about. The rtable for a query
generated by a rule is the concatenation of the original query's rtable
and the rule query's rtable. Therefore the RTE for table1 appears
twice, once in the original INSERT query and once in the generated
UPDATE query
A E wrote:
I guess the question I have then is how do I return data from a
select statement using the record datatype? This is only a test
function I was trying to get info from, but my application is based
on passing the table name to the function dynamically. How do I do
this? The documentation
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
OK, that makes more sense now. But why isn't table2 also in the rule
query's rtable?
It is, but you errored out before getting to it.
The fog has finally started lifting, I think.
Why wouldn't we force checkAsUser to the rule owner
Tom Lane wrote:
No; it's possible for the amalgamated query to include references to
tables that are referenced only in the original query and nowhere in the
text of the rule. (This is obviously possible right now, since we just
take the union of the two rtables and don't make any effort to
Andrew Dunstan wrote:
AFAIK it is not available except for $$$. It looks like the relevant
standards are parts 1 and 2 of the SQLJ standard (Part 0 covers embedded
SQL).
For working drafts try:
http://www.wiscorp.com/sql/sql_2003_standard.zip
(5WD-13-JRT-2003-09.pdf)
Tom Lane wrote:
int32 length word (overall length of datum)
OID type indicator (OID of the composite type)
header fields similar to a normal on-disk tuple
null bitmap if needed
values of fields (themselves also Datums)
Tatsuo Ishii wrote:
It's surprising that nobody noticed the bug until now. It seems it has
been there since 7.3 days. I would like to make a back patch for
7.3-stable if nobody objects.
It's my bug :( -- sorry about that. Here's a 7.3 patch per Tom's nearby
advice. I'll apply if you'd like.
Joe
Tom Lane wrote:
Now, what should we call it instead? I haven't come up with any
compelling thoughts --- the best I can do is big_sort_mem or
single_sort_mem. Surely someone out there has a better idea.
BTW, does anyone want to lobby for renaming sort_mem at the same time?
Since it's used for
Tom Lane wrote:
With this approach, old GUC names would be recognized in SHOW and SET
commands, as well as the other ways you can set a variable by name
(postgresql.conf, ALTER USER SET, etc). But only the new names would
appear in SHOW ALL or the pg_settings view. Does that seem OK?
Seems OK to
Alvaro Herrera wrote:
I think this is most surprising behavior -- shouldn't the UPDATE raise
an error?
Surprising, but not new (probably has been there back to the Berkley
code), and has come up before on one of the lists (I think it might even
have been pgsql-bugs).
regression=# select
[ moving to HACKERS ]
Mark Gibson wrote:
Joe Conway wrote:
Mark Gibson wrote:
[custom datatype oid mismatch between local and remote side of
dblink ]
Without actually having tried it, I think you could hack
pgresultGetTupleDesc() in dblink.c. Replace the line: atttypid =
PQftype(res, i
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Freitag, 6. Februar 2004 10:27 schrieb Thomas Hallgren:
1. Something similar to postgresql.conf (it's not extendable though, is
it?)
No, it is not.
In principle it could be --- the mechanisms already exist in guc.c to
permit outside
Tom Lane wrote:
What do you think of the idea of suppressing the unknown variable
error for some class of variable names?
I like it. I wonder if we ought to have a way to register valid
classes? Maybe a new guc variable in the form of a list of valid
classes. So something like:
Tom Lane wrote:
It's not hard. Start psql, then in another window use ps to determine
the PID of the connected backend. (The pg_stat_activity view might help
too.) Then
gdb /path/to/postgres-executable PID
gdb b whereever
gdb cont
and away you go.
I'd add that when
Christopher Kings-Lynne wrote:
As an implementation issue, I wonder why these things are hacking
permanent on-disk data structures anyway, when what is wanted is only a
temporary suspension of triggers/rules within a single backend. Some
kind of superuser-only SET variable might be a better idea.
Andreas Pflug wrote:
Joe Conway wrote:
Christopher Kings-Lynne wrote:
As an implementation issue, I wonder why these things are
hacking permanent on-disk data structures anyway, when what is
wanted is only a temporary suspension of triggers/rules within
a single backend. Some kind of superuser
Thomas Hallgren wrote:
Some very good suggestions where made here. What happens next? Will this end
up in a TODO list where someone can claim the task (I'm trying to learn
how the process works) ?
If someone doesn't jump right on it and make a diff -c proposal, it
probably belongs on the TODO
Tom Lane wrote:
Confirmations on other platforms please, anyone?
For anyone else who has problems getting it to compile, try copying
the relevant version of pg_dlopen from src/backend/port/dynloader/. I
attach the code I actually ran on HPUX.
FWIW:
RH9
---
# ./eatallfds
Tom Lane wrote:
Hoo, I'm surprised no one noticed this during 7.4 development/testing.
The problem applies for any datatype that requires double alignment,
which includes int8, float8, and timestamp as well as most of the
geometric types. pg_statistic is declared as using type anyarray,
and this
Tom Lane wrote:
I don't have a strong opinion about IN array, but am worried that
allowing it would create ambiguity about which interpretation is meant.
Is the left-hand side supposed to be compared against the whole array or
each array member?
That was exactly the problem. IN (array) does work
Dennis Bjorklund wrote:
The only reason I brought it up was that to me ANY and IN are pretty much
the same kind of operator. Up until now I thought that IN really was the
same as =ANY, but it isn't. I don't like that but of course I have to
accept it. I would rather have had some elem
Tom Lane wrote:
[ wanders away trying to remember that quote about foolish consistency ]
http://www.bartleby.com/59/3/foolishconsi.html
A foolish consistency is the hobgoblin of little minds
A great person does not have to think consistently from one day to the
next. This remark comes from the
Greg Stark wrote:
So in this case if argL or argR are functions or other expressions with
unknown types it tries to figure out how to interpret them to produce the type
it's looking for. In other words, what type those expressions are depends on
what the expression expects. What would you do with
Tom Lane wrote:
One of the things that bothers me about the present PITR design is that
it presumes that individual WAL log segments can be kept until the
external archiver process feels like writing them somewhere. If there's
no guarantee that that happens within X amount of time, then you can't
Simon Riggs wrote:
Tom Lane [mailto:[EMAIL PROTECTED] That should be user-scriptable
policy, in my worldview.
O... and other dbms will freeze when this situation is hit, rather
than continue and drop archive logs.]
Been there, done that, don't see how it's any better. I hesitate to be
real
Rod Taylor wrote:
On Mon, 2004-03-08 at 11:57, Joe Maldonado wrote:
I see that there is an item Queries across databases or servers
(two-phase commit) on the todo list's urgent header. I have tried
asking this question on the other lists and have not yet gotten a
suitable answer to this
Bruce Momjian wrote:
Shridhar Daithankar wrote:
I was wondering what people use to keep track of their personal development
especially when they do not have a cvs commit access.
See the developer's FAQ. They usually use cporig to make copies of
files they are going to modify, then difforig to
Tom Lane wrote:
Well, if you want to think along those lines, I believe that we (PGDG)
currently hold these domain names:
postgresql.org
postgresql.com
postgresql.net
postgres.org
postgres.com
It looks like some domain squatter has his tentacles on
Josh Berkus wrote:
Looks like he hasn't been squatting all that long:
Domain Name: POSTGRES.NET
Created on..: Wed, Aug 07, 2002
Expires on..: Sat, Aug 07, 2004
Record last updated on..: Fri, Oct 31, 2003
Also note the expiration date. Maybe we can
[moving to hackers]
Matthew T. O'Connor wrote:
Good luck, I hope you can get permission. Would e nice to fix this
little crash.
I went ahead and recompiled with --enable-debug, and get this trace:
#0 0xfefb3218 in strlen () from /usr/lib/libc.so.1
#1 0xff006520 in _doprnt () from
Shachar Shemesh wrote:
I'll stress again - I don't mind doing all the work associated with any
once of the above choices. All I'm asking is that we agree on which one
will be best for this project. As far as I'm concerned, Choice 2
involves the least amount of work, but I think Choice 1 will
Fabien COELHO wrote:
Am I unlucky or just blind?
Unlucky I guess. No such function, least not yet.
Joe
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL
Tom Lane wrote:
Although this is quite reasonable for queries submitted by
user-written C functions, I'm worried that plpgsql programmers will
be confused because they've never heard of SPI. I toyed with saying
SQL query instead, but that seems pretty nearly content-free ... it
doesn't
Matthew T. O'Connor wrote:
* Inability to customize thresholds on a per table basis
I ran headlong into this one. IMHO fixing this is critical.
* Inability to set default thresholds on a per database basis
* Inability to exclude specific databases / tables from pg_autovacuum
monitoring
These
Matthew T. O'Connor wrote:
Could you please explain this better, I don't really understand what the
problem is. If you want pg_autovacuum to perform a vacuum on a table
that has had exactly X updates no matter what, you can just run it with
-V0 -vX (where X is the vacuum threshold) same thing
Matthew T. O'Connor wrote:
Joe Conway wrote:
This would be *really* nice to have. In my recent case, if
pg_autovacuum could work for say 3 minutes, and then back off for 2
minutes or so while the batch transactions hit, it would be ideal.
I'm not sure what you are suggesting here. As it stands
Tom Lane wrote:
As an experiment, I made the attached patch that converts add_path's
cost comparisons to fuzzy comparisons --- two paths are considered to
have the same cost if it differs by less than 1% of the smaller
total_cost. I found that this reduced the planning time of Eric's
query by
Neil Conway wrote:
On 28-Mar-04, at 8:32 PM, Joe Conway wrote:
+ * XXX does this percentage need to be user-configurable?
...but I think the answer to the above is yes.
Is this really a parameter that we can expect administrators to be able
to understand and tune very effectively?
I think
I've been seeing 2 regression failures (diff attached) for the past
couple of days. Both appear to be ordering related.
Joe
regression.diffs.gz
Description: GNU Zip compressed data
---(end of broadcast)---
TIP 7: don't forget to increase your
Josh Berkus wrote:
I'm noticing some inconsistent behavior regarding empty arrays and IS NULL
status.For example:
net_test=# select array_upper('{}'::INT[], 1) IS NULL;
?column?
--
t
(1 row)
This is correct. There are no dimensions to an empty array by
definition. The only other
Josh Berkus wrote:
What about a 0?That seems more consistent to me. If the array
is empty, its dimensions are not NULL, meaning unknown, but in
fact zero elements, which is a known value.
They cannot be 0 because 0 is a real index. They are undefined, because
an empty array has no
Greg Stark wrote:
length(a) != array_upper(a)-array_lower(a)
[You really meant array_upper(a) - array_lower(a) + 1 I'd guess]
length(A) is a missing function at the moment; the spec actually calls
it CARDINALITY. Once available, you would use it to determine array
length. SQL2003 says:
The
Greg Stark wrote:
Joe Conway [EMAIL PROTECTED] writes:
Same here; this would be:
array_upper(a || b) == array_upper(a) + CARDINALITY(b)
and would work just fine. Note that if array-a is NULL, then the spec defines a
|| b as NULL. See section 6.35:
Why are you talking about when a is NULL
Greg Stark wrote:
array_lower() and array_upper() are returning NULL for a non-null input, the
empty array, even though lower and upper bounds are known just as well as they
are for any other sized array. They are behaving as if there's something
unknown about the empty array that makes it hard to
Tom Lane wrote:
I think that maybe we ought to question these two properties:
* empty array is different from NULL ... really? Why?
I think this makes sense, similar to the difference between '' and NULL.
* storing a value into an element of a NULL array yields
a NULL
Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
I'm leaning towards suggesting that postgres should follow sql-99 here and
normalize all array indexes to have a lower bound of 1.
That would break even more things, no?
On the other hand, it'd get rid of the problem that we presently face
with
Greg Stark wrote:
I'm leaning towards suggesting that postgres should follow sql-99 here and
normalize all array indexes to have a lower bound of 1. Then array_lower and
array_upper become entirely unnecessary. Instead we just have array_length
which is exactly equivalent to my idea of
Tom Lane wrote:
We have a number of issues revolving around the fact that composite
types (row types) aren't first-class objects. I think it's past time
to fix that. Here are some notes about doing it. I am not sure all
these ideas are fully-baked ... comments appreciated.
[Sorry for the delay
[EMAIL PROTECTED] wrote:
Now I wonder why 7.4 array queries using SOME/ANY/ALL don't make use of
this king of indexes.
Is there any plan to integrate Oleg's job into the core as GiST indexes
were?
I hope to get to it someday, but have higher priorities if I can find
some time between now and the
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
So you mean like an array, but with possibly mixed datatypes?
'{1 , abc def, 2.3}'
Seems to make sense.
The unresolved question in my mind is how to represent NULL elements.
However, we have to solve that sooner or later for arrays too. Any
Greg Stark wrote:
This really ought to work, it obviously shouldn't allow you to set a[5] and
then surreptitiously move it to a[1]. But nor should it generate an error,
since I may well have a specific meaning for a[5] and may be planning to fill
in a[1]..a[4] later.
The logical thing to do, I
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
Almost compatible. I found that, to my surprise, PL/R compiles with no
changes after your commit. However it no segfaults (as I expected) on
composite type arguments. Should be easy to fix though (I think, really
haven't looked at it hard yet
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
/* for tuple args, convert to a one row data.frame */
TupleTableSlot *slot = (TupleTableSlot *) arg[i]; HeapTuple tuples
= slot-val; TupleDesc tupdesc = slot-ttc_tupleDescriptor;
Um. Well, the arg is not a TupleTableSlot * anymore, so
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
... The SRF API was for user defined functions, not
procedural languages anyway. I'll look at how the other procedural
languages handle tuple arguments.
It was a dozen-or-so-lines change in each of the PL languages AFAIR.
You will probably also
Tom Lane wrote:
No, it's a HeapTupleHeader pointer. You need to reconstruct a
HeapTuple on top of that to work with heap_getattr and most other
core backend routines.
Thanks.
For triggers, I was previously building up the arguments thus:
slot = TupleDescGetSlot(tupdesc);
slot-val =
Greg Stark wrote:
Joe Conway [EMAIL PROTECTED] writes:
I agree. I had always envisioned something exactly like that once we supported
NULL elements. As far as the implementation goes, I think it would be very
similar to tuples -- a null bitmask that would exist if any elements are NULL.
Well you
Joe Conway wrote:
Given the above changes, it's almost working now -- only problem left is
with triggers:
insert into foo values(11,'cat99',1.89);
+ ERROR: record type has not been registered
+ CONTEXT: In PL/R function rejectfoo
delete from foo;
+ ERROR: cache lookup failed for type 0
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
For triggers, I was previously building up the arguments thus:
slot = TupleDescGetSlot(tupdesc);
slot-val = trigdata-tg_trigtuple;
arg[7] = PointerGetDatum(slot);
I suppose now I should do this instead?
arg[7
Tom Lane wrote:
If you really want the trigger API for PL/R to be indistinguishable from
the function-call API, then I think you will need to copy the passed
tuple and insert type information. This is more or less what
ExecEvalVar does now in the whole-tuple case (the critical code is
actually in
Tom Lane wrote:
Personally I rely quite a lot on setting PGDATA to keep straight which
installation I'm currently working with, so I'm not going to be happy
with a redesign that eliminates that variable without providing an
adequate substitute :-(
I'll second that.
Joe
mike g wrote:
In file postgresql-7.4.2/src/backend/utils/fmgrtab.c
This is an automatically generated file. The reason for duplicate
array_push declarations is that one-and-the-same array_push function is
used to implement two SQL functions, array_append and array_prepend. I
don't imagine the
Marc G. Fournier wrote:
Why is it the core developers responsibility to make sure that an
application stays in sync with the main tree? Personally, that is giving
life to software that could just as easily be unused by anyone, but kept
in the code base because a commit was made to it less then 6
Bruce Momjian wrote:
I was thinking about CPAN. They have download stuff, but it installs
very easily. I wonder if we should allow gborg projects to interface to
our configure output in a way that makes it easier for them to be
installed.
Now that idea I like. The R project also has something
Bruce Momjian wrote:
I am thinking they could untar into a directory under pgsgl/ or have a
way to point to a 'configure'-run source tree and pull values from
there.
If you include pg_config.h, or use Makefile.global, you have almost
everything you need to compile your own, including flags,
1 - 100 of 1244 matches
Mail list logo
