I know the Information Schema is a SQL standard, but it's somewhat lacking.
I was trying to write a web page that showed a db table,it's columns and
foreign keys.
All went well and I was able to get this tool working great using the
information_schema, problem is that some of the information_sche
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/22/2013 04:17 PM, Joe Conway wrote:
> If you still have a problem please provide SQL that can be cut and
> pasted which: 1) create your table 2) insert sample rows Then show
> us what out put you are trying to acheive as output from th
the
documentation:
http://www.postgresql.org/docs/9.2/interactive/tablefunc.html
If you still have a problem please provide SQL that can be cut and
pasted which:
1) create your table
2) insert sample rows
Then show us what out put you are trying to acheive as output from
that data.
Joe
- --
t (breaking each column on a
separate line) was done to improve readability but it has the side
effect of making the text unreadable if processed via a YAML utility
such as Pyrseas dbtoyaml (since YAML then quotes the entire string and
even breaks it down further with extra backslashes).
Regards,
It's looking like I can use a plpgsql function to insert data into a table
that violates a domain constraint. Is this a known problem?
Session 1:
create domain my_domain text check (length(value) > 2);
create table my_table (name my_domain);
create function f(text) returns void as $$
declare my_
The following bug has been logged on the website:
Bug reference: 7874
Logged by: Joe Van Dyk
Email address: j...@tanga.com
PostgreSQL version: 9.2.1
Operating system: OSX, Linux
Description:
If I run:
alter database foo set my.name = 'joe';
that
> Making use of this seems to fix the original bug - and possibly the
> SIGINT stealing too.
>
> Patch attached to set the variable (R_SignalHandlers = 0), and remove
> the SIGINT workaround.
Cool -- thanks. Maybe that got added in a release since last I looked.
Joe
--
Joe
finish and investigating what's causing the first error
> call.
Yeah -- will do. Thanks!
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
--
Sent via pgsql-bugs mailing list (pg
On 01/24/2013 08:01 PM, Mark Kirkwood wrote:
> Ah right - sorry, I did a quick look for a mail list on the plr web site
> and didn't spot anything.
No problem. It is plr-general on pgfoundry:
http://pgfoundry.org/mail/?group_id=1000247
Joe
--
Joe Conway
credativ LLC: http://www.
On 01/24/2013 05:21 AM, Mark Kirkwood wrote:
> I admit - it sounds unlikely. However a simple scenario (attached) gives
> rise to:
This is the wrong place for the bug report on PL/R I think, but I'll
take a look.
Joe
> WARNING: AbortTransaction while in COMMIT state
> PAN
The following bug has been logged on the website:
Bug reference: 7809
Logged by: Joe Van Dyk
Email address: j...@tanga.com
PostgreSQL version: 9.2.2
Operating system: Ubuntu
Description:
Running pg_dump on a streaming replication slave with a database that has
The following bug has been logged on the website:
Bug reference: 7808
Logged by: Joe Van Dyk
Email address: j...@tanga.com
PostgreSQL version: 9.2.1
Operating system: OSX
Description:
RhodiumToad says this is a bug in unnest, but honestly I don't quite
understa
While browsing the code, "pg_dump.c" the following block *appears* to
be problematic. Additionally, there *appears* to be a malloc without a
free (return or assignment) in the function "getBlobs(Archive *AH)"
(pg_dump.c lines 2169 thru 2188 v9.1.4).
/*
* Each large object has its own BLOB archive
The following bug has been logged on the website:
Bug reference: 6699
Logged by: Joe Van Dyk
Email address: j...@tanga.com
PostgreSQL version: 9.1.4
Operating system: OSX
Description:
$ pg_restore -O -j 4 ~/tanga.dump -d tanga_dev_full_backup
pg_restore: [archiver
The following bug has been logged online:
Bug reference: 6245
Logged by: Joe
Email address: m...@me.com
PostgreSQL version: latest
Operating system: win 7 64 bit
Description:one click Installer problem
Details:
the one click Installer hangs up during installation
hint:
auth-method
Also read:
http://www.postgresql.org/docs/8.4/interactive/contrib-dblink-connect.html
-and-
http://www.postgresql.org/docs/8.4/interactive/contrib-dblink-connect-u.html
HTH,
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Train
repeat the issue in a fresh CentOS VM when I
got home but did not see the problem (perhaps because jade was part of
the install -- will have to check).
Related to this I have noticed in recent weeks on my own development
machine that "make install" takes *much* longer, but only sp
On 02/04/2010 09:37 AM, Joe Conway wrote:
> On 02/04/2010 08:31 AM, Joe Conway wrote:
>> On 02/04/2010 01:23 AM, Fujii Masao wrote:
>>> On Thu, Feb 4, 2010 at 1:26 PM, Joe Conway wrote:
>>>> OK, this one includes pg_dump(all)/pg_restore and common.c from
>>>
On 02/04/2010 08:31 AM, Joe Conway wrote:
> On 02/04/2010 01:23 AM, Fujii Masao wrote:
>> On Thu, Feb 4, 2010 at 1:26 PM, Joe Conway wrote:
>>> OK, this one includes pg_dump(all)/pg_restore and common.c from
>>> bin/scripts (createdb, vacuumdb, etc). I still need to adj
On 02/04/2010 01:23 AM, Fujii Masao wrote:
> On Thu, Feb 4, 2010 at 1:26 PM, Joe Conway wrote:
>> OK, this one includes pg_dump(all)/pg_restore and common.c from
>> bin/scripts (createdb, vacuumdb, etc). I still need to adjust the docs,
>> but other than that any
On 02/02/2010 10:23 PM, Tom Lane wrote:
> Joe Conway writes:
>> Should I also be looking to replace all (or most) other instances of
>> PQsetdbLogin()?
>
> I think we at least wanted to fix pg_dump(all)/pg_restore. Not sure if
> the others are worth troubling over
On 02/02/2010 10:08 PM, Tom Lane wrote:
> Joe Conway writes:
>> Are there any of the psql parameters that we do not want to allow to be
>> overridden by the conninfo string?
>
> Actually, now that I think about it, psql shouldn't be setting
> application_name
cation_name";
values[4] = pset.progname;
keywords[5] = "dbname";
values[5] = (options.action == ACT_LIST_DB &&
options.dbname == NULL) ?
"postgres" : options.dbname;
key
the defaults using connectOptions1(),
applies the supplied other arguments overriding the defaults, and then
finally computes derived options with connectOptions2(). It is
essentially the same as PQconnectdb() except the supplied parameters are
used before setting the derived options.
Joe
signature.asc
Description: OpenPGP digital signature
'd suggest
> something like
>
> keywords[0] = "host";
> values[0] = options.host;
> keywords[1] = "port";
> values[1] = options.port;
Will do.
Joe
signature.asc
Description: OpenPGP digital signature
On 02/02/2010 05:46 PM, Fujii Masao wrote:
> On Wed, Feb 3, 2010 at 10:05 AM, Joe Conway wrote:
>> Objections?
>
> I think that PQconnectdbParams() rather than psql should handle the
> dbname containing "=". Otherwise whenever we use PQconnectdbParams(),
> we woul
gt;> accidental that it did.
>
> No, it was intentional.
Here's a patch.
If "=" is found in the dbname psql argument, the argument is assumed to
be a conninfo string. In that case, append application_name to the
conninfo and use PQsetdbLogin() as before. Otherwise
t;host=localhost" does not exist
>>>
>>> This is because the recently-introduced PQconnectStartParams()
>>> doesn't handle correctly the dbname parameter containing '='.
>
>> Hmm, I don't think that was ever really supposed to work, it
The following bug has been logged online:
Bug reference: 5179
Logged by: Joe Marshal Mathew
Email address: joemarshalmat...@gmail.com
PostgreSQL version: 8.3
Operating system: Windows vista ultimate 64 bit
Description:Installation fails
Details:
The installation
ereport() before PQfinish(conn) in
> dblink_record_internal() when we use temporary connection.
Thanks for the report. Patch applied to HEAD and 8.4 branch. Problem
introduced in 8.4
Joe
signature.asc
Description: OpenPGP digital signature
ing to use them with. For instance, there's
an example of PL/Perl versions available embedded in the code here:
This stuff is pretty trivial to do with PL/R
Joe
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Jul 8, 2009, at 3:42 PM, Tom Lane wrote:
Joe Uhl writes:
On Jul 8, 2009, at 3:00 PM, Tom Lane wrote:
Hmm. In any case that shouldn't have led to a lock left hanging.
Assuming that it was a regular and not autovacuum, do you know what
the exact command would have been? (In parti
On Jul 8, 2009, at 3:00 PM, Tom Lane wrote:
Joe Uhl writes:
On Jul 8, 2009, at 2:41 PM, Tom Lane wrote:
What exactly did you do to "kill" those processes? Do you remember
whether any of them happened to have PID 10453?
I used "kill pid1 pid2 pid3 ..." (no -9) as root.
On Jul 8, 2009, at 2:41 PM, Tom Lane wrote:
Joe Uhl writes:
I had to bounce an OpenMQ broker this morning (this database is the
DB
for an OpenMQ HA setup) and couldn't get it to reconnect to postgres.
On inspecting the database I found dozens of vacuum processes waiting
(I have a cro
or everything including our main product
database (hundreds of transactions/sec, 100's of GB of data) for years
and have never seen this scenario.
Any help is appreciated, I can easily provide any additional
information that may be helpful.
Joe Uhl
--
Sent via pgsql-bugs mailing lis
s used for HMAC. It has the added advantage that
there is no direct storage of the password itself, even in hashed form.
Joe
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
]
dblink.c fix
In dblink.c:785 2nd argument for dblink_get_result(text,bool) is referenced
as 'PG_GETARG_BOOL(2)', must be 'PG_GETARG_BOOL(1)'.
This looks like a correct assessment. Will fix...
Thanks!
Joe
--
Sent via pgsql-bugs mailing list (pgsql-bugs@pos
et The New Boss, Same as the Old Boss" (with the
quotes being part of the title) sorts among the M titles, and not at the
beginning, before the A titles. As I understand, 8.4 will include
LC_COLLATE support at the database rather than cluster level which
should help in this regard.
Joe
--
locale remains en_US.iso88591? And, at
least in theory, if a non-LATIN1 character (like 0x92) is presented to
the converted database, will it be stored as is or silently transformed
(or will an error be issued)?
Joe
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make chang
has both en_US.iso88591
and en_US.utf8 installed but operates mostly with the former)?
As an aside, how can one find the status of a Postgres bug?
Joe
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Possibly, I saw that thread but may not have dug into the content
deeply enough. My apologies if this is the case, i'll check it out
further.
On Sep 10, 2008, at 3:38 PM, Tom Lane wrote:
Joe Uhl <[EMAIL PROTECTED]> writes:
We have a query that returns a different result i
ers.
Please let me know if I can provide any additional information.
Any help is greatly appreciated. I apologize if this is a known
issue, I was unable to turn up a match though struggled to figure out
which search terms might yield a result.
Joe
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
should probably try a bit harder to propagate the
original error fields. I'm inclined to think that it should propagate
sqlstate/message/detail/hint verbatim, and indicate the fact that this
happened on a dblink connection as CONTEXT, rather than structuring the
ereport the way it does now. J
nd is unable to load a DLL
that plr.dll depends on. Again, the "depends" tool can hopefully show
you what's missing there.
That's what I was originally thinking (R.dll), but now I suspect the
exported functions is probably the issue. I'll check this out when I get
ho
ds successfully) and the MSVC Postgres.
Joe
p.s. actual output below
8<--
Welcome to psql 8.3.1, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g
s that to be expected? If so,
can you give me pointers (either direct guidance or literal URLs) on how
to build postgres and related extensions with VC++?
Thanks,
Joe
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ially since this is the first time anyone has complained.
Did you want me to work on this? I could probably put some time into it
this coming weekend.
Joe
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
used (for this data they are
much faster and also don't crash for large datasets).
Mostly I just want to figure out why postgresql is ever returning
out-of-memory rather than using the disk as a backing store. Is my
database misconfigured, or is this a bug? I would think th
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Sorry for the slow response -- I'm at the airport just heading home from
a marathon 30 day business trip.
Yow. Hope you get some time off...
Yeah, I just took a week. Next week I'm back to work and the week after
times. The problem is in
ExecEvalArray, which computes the dimension of the result as [1:2]
even though there are no elements to put in it.
Joe, what do you think about this? Offhand I think that the only
workable definition is that this case yields another zero-dimensional
array, but maybe there is
;--with-openssl" all the time and have never
had a problem. Can anyone comment on the appropriate Makefile changes
for this?
Thanks,
Joe
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
cho
On Wed, Mar 15, 2006 at 01:10:41PM -0500, Tom Lane wrote:
> Joe Sunday <[EMAIL PROTECTED]> writes:
> > On Tue, Mar 14, 2006 at 11:29:57PM -0500, Tom Lane wrote:
> >> What I'd try is first letting the problem case run for a bit, then
> >> stopping it wi
1 0x100ef8a8 in ExecProcNode ()
#12 0x100edea8 in ExecutorRun ()
#13 0x1018519c in ProcessQuery ()
#14 0x10185850 in PortalRun ()
#15 0x1018084c in exec_simple_query ()
#16 0x101825b0 in PostgresMain ()
#17 0x1015510c in ServerLoop ()
#18 0x10155d80 in PostmasterMain ()
#19 0x101101e8 in main ()
On Tue, Mar 14, 2006 at 11:13:38PM -0500, Tom Lane wrote:
> Joe Sunday <[EMAIL PROTECTED]> writes:
> > On Tue, Mar 14, 2006 at 03:56:51PM -0500, Tom Lane wrote:
> >> This error should result in dumping a list of per-context memory usage
> >> into the postmaste
On Tue, Mar 14, 2006 at 03:56:51PM -0500, Tom Lane wrote:
> Joe Sunday <[EMAIL PROTECTED]> writes:
> > 8.1 grows until it uses about 4 GB, at which point it dies with the
> > following error:
> > ERROR: out of memory
> > DETAIL: Failed on request of size 8224.
mp table.
Memory according to top never goes much above 25 megs in use during the query.
8.1 grows until it uses about 4 GB, at which point it dies with the
following error:
ERROR: out of memory
DETAIL: Failed on request of size 8224.
--Joe
--
Joe Sunday <[EMAI
p's caller to
provide the state storage array_map wants, instead of doing it locally.
Both of the existing callers can easily incorporate array_map's state
data into their own state structs. Joe, you have any better ideas?
That certainly looks like the least invasive fix for 8.0.x and
joe=> select to_date('19450323','CCYYMMDD');
to_date
----
2045-03-23
(1 row)
joe=> select to_date('19450323','MMDD');
to_date
1945-03-23
(1 row)
I thought the former would be "more" correct. But it seems I a
t it by hand to see the output.
Tom Lane wrote:
"Joe Brown" <[EMAIL PROTECTED]> writes:
Uncommenting
maintenace_work_mem = 16384
caused the server immediately stop after start.
You apparently managed to change the spelling while uncommenting;
the actual line in th
The following bug has been logged online:
Bug reference: 1466
Logged by: Joe Brown
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.0.0
Operating system: Windows XP
Description:#maintenace_work_mem = 16384
Details:
I was attempting to reduce the already
TE TABLE
regression=# insert into test values ('{"A", "B" }');
INSERT 155428 1
regression=# select * from test;
f1
---
{A,B}
(1 row)
regression=# insert into test values ('{ }');
INSERT 155429 1
regression=# select * from test;
f1
---
{A,B}
{}
(2 rows)
Joe
---(end of broadcast)---
TIP 8: explain analyze is your friend
a look at
it next week.
Joe
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
le. This is more of a conceptual quibble I have at this point.
I think the standard answer should be "do not use serial columns
in any insert rule". I can see problems in cases other than copying
inserted data to another table with rules.
thanks for the good work,
joe
primary key id for my "recipe" table:
>
>SELECT NEXTVAL('recipe_id_seq') FROM receipt;
You're going to get a value for every row in receipt, which is what you're
seeing.
What you want is
SELECT NEXTVAL( 'recipe_id_seq');
--Joe
--
Joe
; the numbers when need arises is MUCH faster than subtracting timestamps and
> parsing the result of such a subtraction.
>
> Note: The 'date' data type does not have this problem. The result of two
> dates subtraction is an integer (not 'interval') which I
Josh Berkus wrote:
Bug: Cannot Use Arrays with Raise Notice in PL/pgSQL.
Version Tested: 7.4.1
Severity: Annoyance
Description:
Attempting to pass an array element to Raise Notice in PL/pgSQL will produce a
parse error:
I can reproduce this with cvs tip -- I'll check into it.
Thanks,
Dennis Bjorklund wrote:
On Thu, 15 Jan 2004, Joe Conway wrote:
Additionally, this behavior was discussed during the 7.4 development and
beta cycles on at least a couple occassions -- that would have been the
time to complain, not now.
Well, I will complain whenever I see something I don't
cases like this.
But I don't see an inherent reason why "raise an error" is better than
"return a null array".
In fact, the above referenced thread shows a scenario where the former
behavior is unpleasant.
I think Joe Conway is planning to tackle that underlying misfeatur
tudio .NET 2003\Common7\IDE".
More than likely you neglected to run vsvars32.bat to set up your
environment correctly.
HTH,
Joe
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
ble-nls \
--enable-debug \
--enable-cassert \
--enable-depend \
--with-openssl \
--with-pam \
--enable-integer-datetimes \
--with-krb5=/usr/kerberos \
--with-includes=/usr/include/et/
The only adjustment from my RH9 box was the last line. Without it
com_err.h wasn't being found.
Joe Conway wrote:
David Fetter wrote:
I have a little puzzlement. In the first select, I double the
backslash and return true. In the second, I don't and get false.
Have I missed something important in the docs?
I don't know if it is clear in the docs anywhere wrt regex, but the
stri
d == d).
The basic rule at work here is you need to double up all backslashes.
HTH,
Joe
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
OK as I'm not currently subscribed.
Cheers, Dave.
Got it.
Joe
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
c\006 | f
| t
\002\003abc\006 | f
(5 rows)
select * from test where b like '\001%';
This is weird. I'm sure it worked at one time -- will research.
Joe
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
POSTGRESQL BUG REPORT TEMPLATE
Your name : Joe Sunday
Your email address : [EMAIL
tions of any trigger functions (particularly any "on delete"
triggers), and if possible a complete reproducible example.
Joe
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
guish between catalog version, meaning
something structural has changed, and catalog-data version which is
correctible by running a script.
Joe
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
was actually a nice behavior.
I found it similarly irritating at first, and it continues to irritate
me. But that may be because I use system tables more frequently than the
average Joe ;-)
I guess I'd be happy to see tab completion reinstated for system tables
(except toast tables as Tom sugge
printf flags, it causes big problems.
This was fixed for 7.3.4 (or so I thought); see:
http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/utils/adt/varlena.c.diff?r1=1.92&r2=1.92.2.1
Are you sure you don't have something earlier? Was does
select version();
d element. Not sure if this works pre-7.4
though -- I know I made some changes related to this, but I forget the
exact details.
Joe
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
pace where nspname like ''pg\_%'')
AND pg_catalog.pg_table_is_visible(c.oid) LOOP
sql := ''grant all on '' || rel.relname || '' to '' || $1;
RAISE NOTICE ''%'', sql;
EXECUTE sql;
END LOOP;
RETURN ''OK&#
mporary tables to be created while using the database.
Are these not working?
HTH,
Joe
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
ce distribution."
I have no idea how to install contrib/array using debian's package
manager, but that's what you need to do.
HTH,
Joe
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
Andres Cuevas wrote:
If data1 or data2 are NULL the request is NULL
Which is the correct behavior, not a bug. See:
http://techdocs.postgresql.org/guides/BriefGuideToNulls
HTH,
Joe
---(end of broadcast)---
TIP 5: Have you checked our extensive
l_service service%ROWTYPE;
BEGIN
SELECT INTO l_service service.* FROM service
WHERE service.service_id = l_service_id;
RETURN l_service;
END;
' LANGUAGE 'plpgsql';
Joe
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
>> Hmmm, looks like nodeFunctionscan.c:tupledesc_mismatch needs to be
>> taught about attisdropped. I'll submit a patch this evening if no
>> one else gets to it first.
>
> Actually, I believe I delibe
x27;ll submit a patch this evening if no one
else gets to it first.
Thanks for the report.
Joe
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
OLD
Data type RECORD; variable holding the old database row for UPDATE/DELETE
operations in ROW level triggers.
It is perhaps confusing, but probably necessary so that a single function can
handle inserts, updates, and deletes (see TG_OP).
Joe
---(end of broa
HERE clause. I was struggling as to where to
be looking. BTW, it was still there after I sync'd up with cvs last night.
Joe
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
1915
#17 0x0811cf9d in ServerLoop () at postmaster.c:1002
#18 0x0811c915 in PostmasterMain (argc=3, argv=0x825cc78) at postmaster.c:781
#19 0x080f930f in main (argc=3, argv=0xb7e4) at main.c:209
Note the line:
#8 0x080ca75a in show_upper_qual (qual=0x82d1d50, qlabel=0x81df318 "Filter"
elein (by way of elein ) wrote:
> This will not work if there is no EOS on the data portion of the
> string. Text fields are not usually stored with the EOS on them,
> are they?
Yes, the TEXT data type is NULL terminated.
Joe
---(end of
-< What is it?
>
> Is that a bug?
It looks like someone dropped user_fomacao_des. What happens if you run:
select * from pg_user;
?
You can fix this by doing:
CREATE USER user_fomacao_des WITH SYSID 131 PASSWORD 'password';
HTH,
Joe
---(end of br
unctionCall1(textout, PointerGetDatum(textp)))
then you can do, e.g.
char *cnum = GET_STR(PG_GETARG_TEXT_P(0));
BTW, there are lots of good examples of C functions in contrib.
HTH,
Joe
---(end of broadcast)---
TIP 1: subscribe and unsubscribe c
table series of actions causes the problem?
Is there a core file and have you looked at it in a debugger?
Joe
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
I think this is probably a must do item for 7.3.
Any further guidance or thoughts?
Thanks,
Joe
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
without a fe/be protocol change, so I'd guess it's a
7.4 issue. But, if there is a way to do it now, and someone gives me a
clue how to proceed, I'll try to get a patch together.
Joe
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
ll the previous tables are back with data in
> it!!
Try connecting to the template1 database, and then do \dt. Do you see
the tables in question?
Joe
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
Joe Conway wrote:
> Bruce Momjian wrote:
>
>> Does this mean we don't have to esacpe >0x7f when inputting bytea
>> anymore?
>
>
> I seem to remember that bytea data was run through the multibute code
> for some reason, and I don't recall seeing th
. I'll search the archives for the
thread.
Joe
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Tom Lane wrote:
> Ah. So the issue is that ANALYZE tries to do textin(byteaout(...))
> in order to produce a textual representation of the most common value
> in the BYTEA column, and apparently textin feels that the string
> generated by byteaout is not legal text. While Joe s
1 - 100 of 107 matches
Mail list logo
