PL/SQL or PL/PGSQL...
Chris
Michael Fuhr wrote:
On Tue, Dec 06, 2005 at 03:31:59PM +0800, Christopher Kings-Lynne wrote:
OK, I give up - how do I convert an INET type to a NUMERIC
representation of its network address?
How about:
CREATE FUNCTION inet2num(inet) RETURNS numeric AS $$
use So
On 12/6/05, Michael Fuhr <[EMAIL PROTECTED]> wrote:
How about:CREATE FUNCTION inet2num(inet) RETURNS numeric AS $$use Socket;return unpack("N", inet_aton($_[0]));$$ LANGUAGE plperlu IMMUTABLE STRICT;
you can use this one:
... AS $$
return unpack("N", pack("C4", split(/\./, $_[0])));
$$ language plp
On Tue, Dec 06, 2005 at 03:31:59PM +0800, Christopher Kings-Lynne wrote:
> OK, I give up - how do I convert an INET type to a NUMERIC
> representation of its network address?
How about:
CREATE FUNCTION inet2num(inet) RETURNS numeric AS $$
use Socket;
return unpack("N", inet_aton($_[0]));
$$ LANG
OK, I give up - how do I convert an INET type to a NUMERIC
representation of its network address?
Is there a quick and easy way?
Chris
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Mon, Dec 05, 2005 at 11:59:10PM -0500, Bruce Momjian wrote:
>> Tom Lane wrote:
>>> The question remains, though, is this computational range good for
>>> anything except demos?
>>
>> I can say that the extended range is good for finding *printf problem
On Mon, Dec 05, 2005 at 11:59:10PM -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > It looks like the limit would be about factorial(256).
> >
> > The question remains, though, is this computational range good for
> > anything except demos?
>
> I can say that the extended range is good for findi
On 12/5/2005 8:18 PM, Gustavo Tonini wrote:
replication (master/slave, multi-master, etc) implemented inside
postgres...I would like to know what has been make in this area.
We do not plan to implement replication inside the backend. Replication
needs are so diverse that pluggable replication
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> If we don't do this then we need to link snprintf into libpgtypes just
> like we do for ecpg, but it seems like overkill.
It might be overkill today, but what about tomorrow when someone decides
to internationalize libpgtypes? I made it link in there
Tom Lane wrote:
Not sure why my build didn't show the problem in pgtypeslib, though.
That should have failed with or without libintl macros.
On *nix it probably just thinks it's an external symbol to be resolved
later.
cheers
andrew
---(end of broadcast)
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Also, we need a way to stop this from happening all over the build:
> In file included from ../../../../../../src/include/c.h:820,
> from ../../../../../../src/include/postgres.h:48,
> from utf8_and_sjis.c:14:
> ../../.
Tom Lane wrote:
> Bruce Momjian writes:
> > The limit seems to be around 150k digits:
>
> It's exactly 10^(128K), as I've mentioned more than once.
>
> > So, with the patch, the storage length is going from 1000 digits to 508,
> > but the computational length is reduced from around 150k digits t
I did some research and can report what was happening with *printf and
libintl.
Basically, there are two versions of libintl. Versions before 0.13
(November 2003) use the libc version of *printf to handle printing of
translation strings. Version 0.13 and after provide their own *printf
function
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
OK, eyeball this for the REL8_1_STABLE branch, please. It seems to
work for me. No exports necessary.
er try this instead. I missed a line from configure.in
I cleaned this up slightly and committed it into HEAD
Hi,
Playing around with this MySQL compatibility library, I noticed that
pg_dump -c does not emit DROP commands for casts. Seems like a bug...?
Chris
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> OK, eyeball this for the REL8_1_STABLE branch, please. It seems to
>> work for me. No exports necessary.
> er try this instead. I missed a line from configure.in
I cleaned this up slightly and committed it into HEAD and 8.1 branches.
It appears to wo
replication (master/slave, multi-master, etc) implemented inside
postgres...I would like to know what has been make in this area.
It's not in the backend, check out things like Slony (www.slony.info)
and various other commercial solutions.
Chris
---(end of broadcast)
Gustavo Tonini wrote:
replication (master/slave, multi-master, etc) implemented inside
postgres...I would like to know what has been make in this area.
http://www.commandprompt.com/ - Master/Slave
Joshua D. Drake
Gustavo.
P.S. Sorry for my bad English.
2005/12/5, Chris Browne <[EMAIL PROT
replication (master/slave, multi-master, etc) implemented inside
postgres...I would like to know what has been make in this area.
Gustavo.
P.S. Sorry for my bad English.2005/12/5, Chris Browne <[EMAIL PROTECTED]>:
[EMAIL PROTECTED] (Gustavo Tonini) writes:> What about replication or data distribu
Qingqing Zhou <[EMAIL PROTECTED]> wrote:
> To reduce size of varlen2.vl_len to int16. This has been mentioned before,
> but is there any show-stopper reasoning preventing us from doing that or
> somebody has been working on it?
Hi, I'm rewriting the patch that I proposed before.
(http://archives.
[EMAIL PROTECTED] (Gustavo Tonini) writes:
> What about replication or data distribution inside the backend. This
> is a valid issue?
I'm not sure what your question is...
--
(reverse (concatenate 'string "gro.gultn" "@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/x.html
"Love is like a snowmobi
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> OK, eyeball this for the REL8_1_STABLE branch, please. It seems to work
> for me. No exports necessary.
OK, I see a few cleanups I want to make, but given the knowledge that
this patch does work on Win32, I should be able to get it done tonight.
Thanks
Andrew Dunstan wrote:
Tom Lane wrote:
I'm coming around to thinking that the simple solution is just to
use it unconditionally on Windows.
I agree that that's what we should do, but it should be done the same
way we handle other routines from libpgport. None of those are exported
to
Tom Lane wrote:
I'm coming around to thinking that the simple solution is just to use it
unconditionally on Windows.
I agree that that's what we should do, but it should be done the same
way we handle other routines from libpgport. None of those are exported
to our client-side programs
Qingqing Zhou <[EMAIL PROTECTED]> writes:
> To reduce size of varlen2.vl_len to int16. This has been mentioned before,
> but is there any show-stopper reasoning preventing us from doing that or
> somebody has been working on it?
> Sorry, just to repeat myself. Char types will benefit from that.
I
On Mon, Dec 05, 2005 at 04:35:31PM -0500, Bruce Momjian wrote:
>
> but it seems this is some BSD'ism that we don't need to support if the
> standard doesn't say so.
I think the Linux manpage is more informative about this:
The functions snprintf and vsnprintf do not write more than
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> Concerning the return value of snprintf(), the SUSv2 and the C99 stan-
> dard contradict each other:
Is that where the problem comes from?
Anyway, I've added some text to snprintf.c explaining what we do. Since
the calling code has to be prepa
To reduce size of varlen2.vl_len to int16. This has been mentioned before,
but is there any show-stopper reasoning preventing us from doing that or
somebody has been working on it?
Sorry, just to repeat myself. Char types will benefit from that. Many
applications are from DB2, Oracle or SQL Serve
Bruce Momjian writes:
> Upon successful completion snprintf() and vsnprintf() return the number
> of characters that would have been written to a sufficiently sized str,
> excluding the terminating NUL character.
> but it seems this is some BSD'ism that we don't need to support
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom, did you implement this functionality in *printf?
> > The size may be given as zero to find out how many characters are
> > needed; in this case, the str argument is ignored. Sprintf() and
> > vsprintf() effectively assume an infinite siz
Bruce Momjian writes:
> Tom, did you implement this functionality in *printf?
> The size may be given as zero to find out how many characters are
> needed; in this case, the str argument is ignored. Sprintf() and
> vsprintf() effectively assume an infinite size.
Where do you rea
Tom, did you implement this functionality in *printf?
The size may be given as zero to find out how many characters are
needed; in this case, the str argument is ignored. Sprintf() and
vsprintf() effectively assume an infinite size.
Looking at the code it doesn't seem supp
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>>> The problem is that the alias will be picked up by every libpq client.
>>
>> Not at all; libpq clients do not import c.h.
> Well, all the programs that use postgres-fe.h do.
Sure, but a
I wrote:
> The way the attached patch attacks this is for the shared-lock access
> case to simply set the page's LRU counter to zero, without bumping up
> the LRU counters of the other pages as the normal adjustment would do.
> ...
> I'm not totally happy with this heuristic, though, and was
> wond
What about replication or data distribution inside the backend. This is a valid issue?
Thanks,
Gustavo.
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What about Plan B? Per Bruce's comment, it should really only be ecpg
>> that needs an extra copy of snprintf.o, and it's not like ecpg doesn't
>> already pull in various port/ files for itself.
> The problem is that the alias will b
Jan Wieck írta:
On 12/5/2005 1:03 PM, Zoltan Boszormenyi wrote:
Jan Wieck írta:
On 12/4/2005 5:10 PM, Zoltan Boszormenyi wrote:
I found this in the SQL2003 draft:
"
4.14.7 Identity columns
... An identity column has a start value, an increment, a maximum
value, a minimum value,
and a c
-Original Message-
From: "Andrew Dunstan"<[EMAIL PROTECTED]>
Sent: 05/12/05 19:03:17
To: "Tom Lane"<[EMAIL PROTECTED]>
Cc: "Bruce Momjian", "[EMAIL PROTECTED]"<[EMAIL
PROTECTED]>, "[EMAIL PROTECTED]"<[EMAIL PROTECTED]>, "[EMAIL PROTECTED]"<[EMAIL
PROTECTED]>, "pgsql-hackers@postgresql.or
On 12/5/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Not only does 4000! not work, but 400! doesn't even work. I just lost
> > demo "wow" factor points!
>
> It looks like the limit would be about factorial(256).
>
> The question remains, though, is this computational range good for
> anything excep
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
The bad news: if we aren't compiling with NLS enabled, having those
entries in exports.txt makes the libpq build blow up. So either we need
to use pg_*printf unconditionally on Windows, or we need a little
Makefile + sed magic to
Bruce Momjian writes:
> The limit seems to be around 150k digits:
It's exactly 10^(128K), as I've mentioned more than once.
> So, with the patch, the storage length is going from 1000 digits to 508,
> but the computational length is reduced from around 150k digits to 508.
> Now, because no one
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> With luck I can probably wrap this up today for the 8.1 stable branch -
> it would be nice if the new release actually did NLS right.
BTW, core has already agreed to postpone the releases a couple days
while we make sure we have this problem nailed dow
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The bad news: if we aren't compiling with NLS enabled, having those
> entries in exports.txt makes the libpq build blow up. So either we need
> to use pg_*printf unconditionally on Windows, or we need a little
> Makefile + sed magic to strip those ent
On 12/5/2005 1:03 PM, Zoltan Boszormenyi wrote:
Jan Wieck írta:
On 12/4/2005 5:10 PM, Zoltan Boszormenyi wrote:
I found this in the SQL2003 draft:
"
4.14.7 Identity columns
... An identity column has a start value, an increment, a maximum
value, a minimum value,
and a cycle option. ...
"
Bruce Momjian wrote:
Was the last patch you sent in ready for application, or are you still
fooling with it?
He is still working on it. It did not handle all *printf functions, as
he mentioned, and he might have other changes.
Yeah.
The good news: the new pg_*printf does the rig
[ Moved to hackers for patch discussion.]
John D. Burger wrote:
> >> There are practical applications, eg, 1024-bit keys are fairly common
> >> objects in cryptography these days, and that equates to about 10^308.
> >> I don't really foresee anyone trying to run crypto algorithms with SQL
> >> NU
Jan Wieck írta:
On 12/4/2005 5:10 PM, Zoltan Boszormenyi wrote:
I found this in the SQL2003 draft:
"
4.14.7 Identity columns
... An identity column has a start value, an increment, a maximum
value, a minimum value,
and a cycle option. ...
"
The exact properties of a sequence. It would be
[snip]
> I want to be sure my existing queries keep using the plans they've been using
> until I allow them to change.
>
> I don't want to sit down and type "select count(*) from users" and have it not
> work correctly (ie, use a sequential scan) because the system is so single
> mindedly tuned fo
Hans-Juergen Schoenig <[EMAIL PROTECTED]> writes:
> I think I know what Greg is trying to say: I think in this plan stability
> does not mean that the plan has to be completely fixed - usually it is all
> about indexing.
"Usually" problems occur because someone hasn't run analyze at all. That's
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > With 8.1_RC1 I *do* get the results Nicolai reported. With the changes I
> > made yesterday, I see the result above, i.e. what we expect from our own
> > breakage of sprintf (i haven't yet updated the snapshot I took).
>
> Ah. OK,
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> With 8.1_RC1 I *do* get the results Nicolai reported. With the changes I
> made yesterday, I see the result above, i.e. what we expect from our own
> breakage of sprintf (i haven't yet updated the snapshot I took).
Ah. OK, that makes sense.
> But th
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
What is more, when I set the locale of my machine to Turkish and run the
installer project's 8.1_RC1 which I happen to have installed there, and
set lc_messages to tr_TR.UTF-8, I don't see lines like Nicolai reported:
LOG: "$s"
Tom Lane wrote:
> The concern about deadlock applies to the various proposals that involve
> upgrading to a write-prevention lock at some late point in the process.
> That clearly has the potential to deadlock against relatively weak lock
> requests.
After looking at the various lock types, I don'
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> What is more, when I set the locale of my machine to Turkish and run the
> installer project's 8.1_RC1 which I happen to have installed there, and
> set lc_messages to tr_TR.UTF-8, I don't see lines like Nicolai reported:
> LOG: "$s" veritaban?n tra
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
However, a very simple test shows that the libintl printf does indeed do
%m$ processing:
...
So the next question is why isn't it working in the build.
Is it possible that the build that was being complained of was using ou
I wonder if it would work to release the AccessShareLock before
acquiring the ExclusiveLock. Of course, this would let any ALTER TABLE
or DROP TABLE to do anything they wanted, but we could check that the
table is still the same after reacquiring the exclusive lock. REINDEX
would have to abort if
Kevin Brown <[EMAIL PROTECTED]> writes:
> And now I see why, since it will introduce deadlocks (sigh). But what
> of the other rule (always acquiring locks against the table before the
> index)? You may have stopped reading at the above...
We already do that.
> One thing I don't quite understan
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> However, a very simple test shows that the libintl printf does indeed do
> %m$ processing:
> ...
> So the next question is why isn't it working in the build.
Is it possible that the build that was being complained of was using our
previous, very-broken
I wrote:
Bruce Momjian said:
OK, a few things. First, Tom has fixed snprintf.c so it should
properly process positional parameters now. Would you first test the
libintl version of *printf to see if it can process %$ parameters
(probably by hacking up any language file and testing the prin
Ühel kenal päeval, R, 2005-12-02 kell 02:14, kirjutas Tom Lane:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > It was a *major* new feature that many people were waiting for when Oracle
> > finally implemented live CREATE INDEX and REINDEX. The ability to run create
> > an index without blocking any
On Sun, Dec 04, 2005 at 10:40:55PM -0800, Kevin Brown wrote:
> One thing I don't quite understand about the discussion is why there's
> particular attention being paid to deadlocks with respect to REINDEX
> when it clearly can happen in the general case when lock promotion is
> involved. Why is RE
On Dec 5, 2005, at 4:17 AM, Tom Lane wrote:
Greg Stark <[EMAIL PROTECTED]> writes:
Plan stability is also an important feature, especially for OLTP
systems which have hard real-time requirements. OLTP systems
typically
don't care about getting the "best" plan for a query, only a plan
that
On Mon, 2005-12-05 at 01:53 -0500, Greg Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
> > There is no such thing as a plan
> > that is good for every case --- outlying data values can make a
> > usually-good plan blow out your performance guarantee anyway.
>
> But outlying data is somethin
On Sun, 2005-12-04 at 13:47 -0500, Pollard, Mike wrote:
> Simon Riggs wrote
> > The system default is to have a prepared statement
> > bound to a plan on its first parameter bind.
>
> We call it deferred optimization.
>
> Do you really stop at the first parameter?
The first bind of parameter
On Sun, 2005-12-04 at 12:49 -0300, Alvaro Herrera wrote:
> Simon Riggs wrote:
>
> > ISTM we could do some of that with another GUC, lets call it
> > prepare_once = on. The system default is to have a prepared statement
> > bound to a plan on its first parameter bind. If we set this to "off",
> > t
64 matches
Mail list logo
