Re: [HACKERS] timestamp/date in ecpg
On Fri, Mar 21, 2003 at 04:33:09PM +0100, Christoph Haller wrote: Hmm, maybe the transformation in the other direction is the culprit. What I do is call ts1 = PGTYPEStimestamp_atot(2000-7-12 17:34:29, NULL); followed by a text = PGTYPEStimestamp_ttoa (ts1); Needless to say the resulting text is not 2000-7-12 17:34:29. :-( I could not dig too deep into the code until now, but isn't there a leading zero missing 2000-07-12 17:34:29 Sure, but that shouldn't be a problem. Note, however, that I just ran a short test that worked as advertized. Right now it seems ecpglib does call the new functions incorrectly. When calling them directly it seems to work. Unfortunately I have no time to dig into it right now. But I surely will soon. Michael -- Michael Meskes Email: [EMAIL PROTECTED] ICQ: 179140304 Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Please clarify with regard to Renaming a Sequence
From what I can see the sequence name is not changed when you rename a
table
test=# alter table fooseq rename to fooseq1;
ALTER TABLE
test=# \d fooseq1
Table public.fooseq1
Column | Type | Modifiers
+-+
id | integer | not null default
nextval('public.fooseq_id_seq'::text)
so everything should work as expected.
Dave
On Fri, 2003-03-21 at 09:38, Anand B Kumar wrote:
Dear Sirs,
We are working on Postgresql for one of our on going project. We have
come across a situation as mentioned below.
1. We have to create a table with sequence dynamically from the front
end ( through a JSP code)
2. An option for the user is given to change the name of the table in
the front end. During this process, we change the name of the table
and its relative sequence too. But the table which was first created
with a sequence has its property written in its property field. Now
if we change that property in that field, will the sequence gets
disturbed??
For say, I create a table 'addrtech' which has two fields, empid and
empname
2. The emp id has a sequence created dynamically. so a sequence
name addrtech_empid_seq is created.
3. The field empid in addrtech has in its DEFAULT column as
nextval('addrtech_empid_seq'::text)
4. Now I rename addrtech to addrtechnology
5. So the table is altered
6. The sequence is also altered as addrtechnology_empid_seq and the
new table is addrtechnology
But the doubt now is the field which has the sequence i.e the empid
which has nextval('addrtech_empid_seq'::text) . The property if
changed to nextval('addrtechnology_empid_seq'::text) will the
seqeunce remain the same. Meaning if it had some few million records
in the orginial table addrtech and if additional data is entere to
addrtechnology will the sequence continue.
Please clarify this query of mine at the earliest so that we can
incorporate the same in our codes
Your early reply is solicitated
regards
Andy
__
Upgrade Your Email - Click here!
--
Dave Cramer [EMAIL PROTECTED]
Cramer Consulting
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PQescapeBytea on Win32
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Doesn't this duplicate a function that we already invented for PQnotify structs? What do you recommend? Do we depricate PQfreeNotify? I dunno. In hindsight it was shortsightedly named. But I don't suppose we want to tell people to use PQfreeNotify to free the result of PQescapeBytea ... so deprecation seems to be the order of the day. Do we really want PQfreemem either? Maybe it should be PQfree? I am a little concerned that PQfree would be confused with PQclear. Could we have PQfreeNotify() be a macro to PQfreemem in 7.4? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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
[HACKERS] Fwd: [GENERAL] statement id
No response on general to my sort of esoteric question... Any info here on hackers? --elein -- Forwarded Message -- Subject: [GENERAL] statement id Date: Tue, 18 Mar 2003 19:03:35 -0800 From: elein [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Is there any way to find out the statement context in a server function? Is there anyway to find out the transaction context in a server function? I have a plpython function I want to run and it can store data for the context of a session. But I only want the memory to last the duration of a statement or a transaction. It is not a trigger function which has a transaction dictionary. If I knew the statement or transaction id I could initialize the memory for multiple calls within the session. Statement (subselect) level would be best as it would enable managing data from several calls to the same function. Sort of. If this were a C function, would it be easier to have this information? thanks, elein -- - --- [EMAIL PROTECTED] Database Consulting www.varlena.com I have always depended on the [QA] of strangers. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) --- -- [EMAIL PROTECTED] Database Consulting www.varlena.com I have always depended on the [QA] of strangers. ---(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
Re: [HACKERS] A bad behavior under autocommit off mode
Tom Lane writes: I had originally been thinking of reporting client_encoding as a field of some message sent only at backend startup. However, what if we send such a message whenever one of the variables it includes changes? The silent assumption behind the client_encoding parameter is that you must set it to the actual character set encoding used by the client. If you lie, the results are unspecified. So if you're in a JDBC application and set the client encoding to an encoding that the JDBC driver (that is, the client) cannot handle, you lied and you deserve to lose. (Really, this problem can only occur in applications that let random users enter random commands or if a programmer is explicitly trying out forbidden territory.) There are real and valid reasons for changing the client encoding on the fly, but that is no reason to make a big deal about passing the information around all the time. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] PQescapeBytea on Win32
Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Doesn't this duplicate a function that we already invented for PQnotify structs? What do you recommend? Do we depricate PQfreeNotify? I dunno. In hindsight it was shortsightedly named. But I don't suppose we want to tell people to use PQfreeNotify to free the result of PQescapeBytea ... so deprecation seems to be the order of the day. Do we really want PQfreemem either? Maybe it should be PQfree? I am a little concerned that PQfree would be confused with PQclear. Could we have PQfreeNotify() be a macro to PQfreemem in 7.4? The only place I see PQfreeNotify() used in our code is libpgtcl, aside from libpq, and a macro would work fine. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PQescapeBytea on Win32
Bruce Momjian [EMAIL PROTECTED] writes: Do we really want PQfreemem either? Maybe it should be PQfree? I am a little concerned that PQfree would be confused with PQclear. Good point --- nevermind that suggestion. Could we have PQfreeNotify() be a macro to PQfreemem in 7.4? I'd like to do that but I doubt we can get away with it; it'd be an incompatible change at the binary API level, forcing a major version bump on libpq.so. (On the other hand, we might wind up doing one anyway; not sure.) You could do it the other way: PQfreemem a macro for PQfreeNotify. That would stay binary-compatible with existing clients. We could switch which one is a macro at the next occasion for a major version bump on the shlib, and then eventually remove PQfreeNotify when we feel it's been deprecated for long enough. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] PQescapeBytea on Win32
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Do we really want PQfreemem either? Maybe it should be PQfree?
I am a little concerned that PQfree would be confused with PQclear.
Good point --- nevermind that suggestion.
Could we have PQfreeNotify() be a macro to PQfreemem in 7.4?
I'd like to do that but I doubt we can get away with it; it'd be
an incompatible change at the binary API level, forcing a major
version bump on libpq.so. (On the other hand, we might wind up
doing one anyway; not sure.)
Right. We changed the Notify internal structure and got bitten on that
in 7.3 -- don't want that to happen again.
You could do it the other way: PQfreemem a macro for PQfreeNotify.
That would stay binary-compatible with existing clients. We could
switch which one is a macro at the next occasion for a major
version bump on the shlib, and then eventually remove PQfreeNotify
when we feel it's been deprecated for long enough.
The problem with that is the new versions are still going to reference
PQfreeNotify, and then we still can't remove it. I think we need the
macro for PQfreeNotify pointing to PQfreemem, but keep the PQfreeNotify
function around for a release or two, then remove it, and remove all
documentation about it in 7.4.
I now see that psql doesn't use that call, though it should if it is
running on Win32:
static void
PrintNotifications(void)
{
PGnotify *notify;
while ((notify = PQnotifies(pset.db)))
{
fprintf(pset.queryFout, gettext(Asynchronous NOTIFY '%s' from backend
w
ith pid %d received.\n),
notify-relname, notify-be_pid);
free(notify);
fflush(pset.queryFout);
}
}
I will clean that up too, and check any other interfaces/apps.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Fwd: [GENERAL] statement id
elein wrote: Is there any way to find out the statement context in a server function? Is there anyway to find out the transaction context in a server function? [...snip...] If this were a C function, would it be easier to have this information? I don't know anything about plpython, but I'd guess the info you're looking for is not available to it. In C, I think (but have not tried) you could use GetCurrentTransactionId() to put the current transaction id into a global variable, and allocate memory for other globals in TopTransactionContext. Then use a change in transaction id to signal a need to reallocate/reinitialize your globals. Not sure if this is what you were looking for, but HTH. 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
[HACKERS] IS OF
While messing around in gram.y I came across a production like this:
| a_expr IS OF '(' type_list ')' %prec IS
{
$$ = (Node *) makeSimpleA_Expr(AEXPR_OF, =, $1, (Node *) $5);
}
| a_expr IS NOT OF '(' type_list ')' %prec IS
{
$$ = (Node *) makeSimpleA_Expr(AEXPR_OF, !=, $1, (Node *) $6);
}
Works like so:
regression=# select array[1,1.2] is of (numeric[]);
?column?
--
t
(1 row)
Pretty handy! But I couldn't find it documented anywhere -- is it?
Thanks,
Joe
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] IS OF
Joe Conway [EMAIL PROTECTED] writes: Pretty handy! But I couldn't find it documented anywhere -- is it? I think Thomas did that in one of his last batches of changes, and then disappeared without adding the documentation. Feel free to contribute some. I believe it is supposed to be a SQL99 feature, so you might see if the spec sheds any light ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Fwd: [GENERAL] statement id
Yes, this is exactly what I'm looking for. I was hoping the connection context information might be available in one of the stat tables, some SQL variable or function call. The ability to have data persist across function calls without having to resort to C is really very useful, but having some context information is crucial. elein On Saturday 22 March 2003 15:48, Joe Conway wrote: elein wrote: Is there any way to find out the statement context in a server function? Is there anyway to find out the transaction context in a server function? [...snip...] If this were a C function, would it be easier to have this information? I don't know anything about plpython, but I'd guess the info you're looking for is not available to it. In C, I think (but have not tried) you could use GetCurrentTransactionId() to put the current transaction id into a global variable, and allocate memory for other globals in TopTransactionContext. Then use a change in transaction id to signal a need to reallocate/reinitialize your globals. Not sure if this is what you were looking for, but HTH. Joe -- [EMAIL PROTECTED] Database Consulting www.varlena.com I have always depended on the [QA] of strangers. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] IS OF
On Sat, 22 Mar 2003, Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: Pretty handy! But I couldn't find it documented anywhere -- is it? I think Thomas did that in one of his last batches of changes, and then disappeared without adding the documentation. Feel free to contribute some. I believe it is supposed to be a SQL99 feature, so you might see if the spec sheds any light ... 8.14 type predicate to be exact. Gavin ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] IS OF
Gavin Sherry wrote: 8.14 type predicate to be exact. 8.18 in SQL200x. I don't think the current implementation quite meets the spec however: regression=# select f2 is null, f2 is of(int) from bar; ?column? | ?column? --+-- f| t t| t (2 rows) If I read the spec correctly, the null value should return null, not 't' in the above. General Rules 1) Let V be the result of evaluating the row value predicand. 2) Let ST be the set consisting of every type that is either some exclusively specified type, or a subtype of some inclusively specified type. 3) Let TPR be the result of evaluating the type predicate. Case: a) If V is the null value, then TPR is Unknown. b) If the most specific type of V is a member of ST, then TPR is True . c) Otherwise, TPR is False Probably best not to document it until someone gets around to fixing it -- I can do it, but not for the next few weeks at least. Joe ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] cursors: SCROLL default, error messages
On Fri, 2003-03-21 at 17:38, Tom Lane wrote: AFAICS, our CVS-tip behavior is a reasonable superset of the spec. We don't have the NO SCROLL noiseword (which was not in SQL92 anyway), but otherwise I'm happy with what's there now. Yeah, I guess there's no need to actual enforce NO SCROLL -- but IMHO, it makes the most sense to do so. If the user explicitly says that the cursor can't be used for scrolling, allowing scrolling only serves to make things more confusing, IMHO. In other words, who is *actually* going to specify NO SCROLL, and then expect to scroll the cursor? I'd say just about no one, intentionally -- so if that situation occurs, it is probably the result of programmer error, and we should flag it for standards compliance. Cheers, Neil ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] cursors: SCROLL default, error messages
Neil Conway [EMAIL PROTECTED] writes: In other words, who is *actually* going to specify NO SCROLL, and then expect to scroll the cursor? I'd say just about no one, intentionally -- Well, if you want to do a three-way switch as per earlier discussion, I won't object. I can't get real excited about it though. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] conversion problems with domains
Andreas Pflug [EMAIL PROTECTED] writes: PostgreSQL 7.3.2 CREATE DOMAIN testdom AS int4; CREATE TABLE testtab(testcol testdom); INSERT INTO testtab VALUES (1); INSERT INTO testtab VALUES (2); VACUUM ANALYZE testtab; SELECT * FROM testtab WHERE testcol 1; I've applied a patch to fix this. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Domain breakage
Here's a fun one: in 7.3 or CVS tip, try regression=# create domain tint as int; CREATE DOMAIN regression=# select 1::tint (-1); ?column? -- t (1 row) regression=# select 1::tint (-1)::tint; ?column? -- f (1 row) How's that again? Well, when you dig into it you find that the second case is invoking the OID greater-than operator (oidgt), which does unsigned comparison. Why is it picking oidgt and not int4gt, considering that the domain is based on int4? Well, the problem is that the domain type is considered binary-compatible with both int4 and oid; there isn't any stronger connection to the base type than there is to any other type that's binary-compatible with the domain. So oper_select_candidate gets down to its third tiebreaker, preferred-type status ... and guess what, OID is a preferred type in its category while int4 is not preferred in its category. I suspect that the most workable fix for this is to reduce all the input typeids to base types before we start the operator or function type resolution routines. However, this would completely destroy any hope of making domain-specific operators. (I'm also reminded once again that I don't like the preferred-type heuristics. They're too likely to produce surprising choices.) A different line of attack would be to modify the operator/function resolution rules to take account of domain relationships explicitly, making the binding of domain to base type stronger than mere binary equivalence. But I'm not clear how that might work. Any ideas? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PQescapeBytea on Win32
Bruce Momjian [EMAIL PROTECTED] writes: The problem with that is the new versions are still going to reference PQfreeNotify, and then we still can't remove it. I think we need the macro for PQfreeNotify pointing to PQfreemem, but keep the PQfreeNotify function around for a release or two, then remove it, and remove all documentation about it in 7.4. Hm. You could possibly do that with some judicious #undef'ing ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] A bad behavior under autocommit off mode
Peter Eisentraut [EMAIL PROTECTED] writes: The silent assumption behind the client_encoding parameter is that you must set it to the actual character set encoding used by the client. If you lie, the results are unspecified. So if you're in a JDBC application and set the client encoding to an encoding that the JDBC driver (that is, the client) cannot handle, you lied and you deserve to lose. I think the issue is not so much whether the JDBC driver *can* handle the encoding, as whether it knows what it needs to be doing right now. There are real and valid reasons for changing the client encoding on the fly, but that is no reason to make a big deal about passing the information around all the time. If the JDBC driver needs to do anything different for one encoding than another, then it needs to be informed of changes. We can debate what's the most appropriate way to keep it informed, but I don't think we can just ignore the need to inform it. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PQescapeBytea on Win32
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: The problem with that is the new versions are still going to reference PQfreeNotify, and then we still can't remove it. I think we need the macro for PQfreeNotify pointing to PQfreemem, but keep the PQfreeNotify function around for a release or two, then remove it, and remove all documentation about it in 7.4. Hm. You could possibly do that with some judicious #undef'ing ... Exactly! -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] regproc's lack of certainty is dangerous
I wrote: I think that we can actually get away (from an implementation point of view) with a column containing arrays of different base types; array_out will still work AFAIR. It's an interesting question though how such a column could reasonably be declared. This ties into your recent investigations into polymorphic array functions, perhaps. Maybe anyarray shouldn't be quite so pseudo a pseudotype? I have committed a fix for these problems that makes pg_statistic's columns into anyarray columns. It turns out that my original concerns about datatypes without associated array types don't matter --- we can physically build such an array, regardless of whether we can point to a pg_type entry that describes it. This is certainly something of a kluge at the moment, because pg_statistic is making use of facilities that don't exist at the SQL level. It gets the job done, but I'd like to see some fuller support for anyarray in future. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
