; Documentation:tested, passed
>
> Hello Anthony,
>
> Great job!
>
> I decided to take a closer look on your patch. Here are some defects
> I discovered.
>
> > + Additional extensions are available that implement transforms
> > for
> > + the jsonb typ
b_plpython3u
"make install" checks which python major version was your postgresql
configured with and installs corresponding extension.
--
Anthony Bykov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
ascade;
create or replace function test(val jsonb)
returns jsonb
transform for type jsonb
language plpython2u
as $$
return (val);
$$;
select test('{"1":1,"example": null}'::jsonb);
--
Anthony Bykov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Co
There are some moments I should mention:
1. {"1":1}::jsonb is transformed into HV {"1"=>"1"}, while
["1","2"]::jsonb is transformed into AV ["1", "2"]
2. If there is a numeric value appear in jsonb, it will be transformed
to SVnv through string (Numeric->String->SV->SVnv). Not the best
solution, b
Hello.
Please, check out jsonb transform
(https://www.postgresql.org/docs/9.5/static/sql-createtransform.html)
for pl/perl language I've implemented.diff --git a/contrib/Makefile b/contrib/Makefile
index 8046ca4..53d44fe 100644
--- a/contrib/Makefile
+++ b/contrib/Makefile
@@ -75,9 +75,9 @@ ALWAYS_
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Hello,
I've tested it (make check-world) and as far as I unde
(correct me if I'm wrong)
for users. Shouldn't there be any changes in doc/src/sgml/ with the description
of new functionality?
Regards
Anthony
The new status of this patch is: Waiting on Author
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
I'm afraid this patch conflicts with current master branch.
The new status
NT to
12 in trgm.h I still get trigram results for show_trgrm() . I was hoping
someone familiar with it could provide a little help for me by perhaps
giving me a path of action needed to change the trigram implementation to
behave as an n-gram. Thanks for your time and I appreciate any advice anyone
c
(in particular for pivoting so you don't need to have extra tables
lying around).
It's a cool addition and I've gotten positive feedback from it.
So, whoever dreamt it up, nice job. :)
Thanks and regards,
Anthony
-Original Message-
From: Josh Berkus [mailto:[EMAIL PROTECTE
year and was wondering if you guys are still
planning on added the window functions added to the '03 standard?
I have a ton of recipes that use them and if you guys are still
planning on implementing them, I'd like to mention that as well.
Thanks,
Anthony
-Original Message-
So is postgresql going into the direction of WITH or CONNECT BY (or
both)?
I am authoring O'Reilly's "SQL Cookbook" and I'd like to mention it in
the
Hierarchical chapter to give the pg readers a heads up.
Thanks and regards,
Anthony Molinaro
-Original Message---
Hi Guys,
I have a suggestion for fixing a long-term and painful
problem in PostgreSQL that is holding up many very
important commercial projects, including ours!
This problem has been reported numerous times:
When one process has a "row lock" on one or more rows
in a table, using "SELECT...FOR UP
In article <[EMAIL PROTECTED]>, Lauri Pietarinen
<[EMAIL PROTECTED]> writes
>Anthony W. Youngman wrote:
>>In article <[EMAIL PROTECTED]>, Lauri Pietarinen >[EMAIL PROTECTED]> writes
>>>Anthony W. Youngman wrote:
>>>>In article <[EMAIL PRO
In article <[EMAIL PROTECTED]>, Lauri Pietarinen writes
>Anthony W. Youngman wrote:
>
>>In article <[EMAIL PROTECTED]>, Lauri Pietarinen
>><[EMAIL PROTECTED]> writes
>>
>>
>>>Anthony W. Youngman wrote:
>>>
>>>
>&
d about is that there is
room for about 5% improvement before we hit that mathematical limit. SQL
has a HELL of a long way to go to catch up :-)
Cheers,
Wol
--
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
Witches are curious by definition and inquisitive by nature. She moved in
In article <[EMAIL PROTECTED]>, Anthony W. Youngman
<[EMAIL PROTECTED]> writes
>>Really, however you calculate it, it is an order of magnitude less
>>than your alternative.
>>
>>And please don't tell me that using indexes is not fair or not in the
>&
d they were to beat this MV system! Yet with
hardware that was so much more powerful and a query that was heavily
optimised, they had great difficulty beating a query that was thrown
together in seconds by an average MV guy (or even just a luser!).
Don't forget. I said I am a database *engi
In article <[EMAIL PROTECTED]>, Lauri Pietarinen
<[EMAIL PROTECTED]> writes
>Anthony W. Youngman wrote:
>
>>Well, as far as we MV'ers are concerned, performance IS a problem with
>>the relational approach. The attitude (as far as I can tell) with
&g
In article <[EMAIL PROTECTED]>, Paul Vernon
<[EMAIL PROTECTED]> writes
>No, I think Anthony is just saying that he doesn't "believe" in science/the
>scientific method. Or maybe he believes that engineering is not based on
>scientific knowledge!
Actually, I *
In article <[EMAIL PROTECTED]>, Lauri Pietarinen
<[EMAIL PROTECTED]> writes
>Anthony W. Youngman wrote:
>
>>
>>Fine. But MV *doesn't* *need* much of a cache. Let's assume both SQL and
>>MV have the same amount of RAM to cache in - i.e. *not* *muc
in memory. Pick optimises the hard task
of getting it into memory in the first place".
"Relational" is all about theory and proving things mathematically
correct. "MV" is all about engineering and getting the result. And if
that means pinching all the best ideas we can find fr
teach to everyone
else, and the end result is that all research is ploughed into a model
that may be (I didn't say "is") bankrupt. Just like the academics were
brainwashed into thinking that microkernels were the be-all and end-all
- until Linus showed them by practical example that
>elegance and mathematical principles.
Mathematical principles? You mean like Euclidean Geometry and Newtonian
Mechanics? They're perfectly solid, good, mathematically correct. Shame
they don't actually WORK all the time in the real world.
That's what I feel about relational, too ...
C
real
world.
That said, I always think relationally when designing databases - it
helps. Look at the multi-value databases. Think relationally, you can
still store your data in normal form, but you're not stuffed by all the
irrelevant restrictions that relational databases tend to impose.
hi
postgresql supports dynamic sql with parameters in SQL function bodies,
but not in interactive queries. why?
when i wrote a dynamic sql with parameters, ODBC just filled the values of
parameters into query string and sent it to server as a static query string.
i think it's not right sol
How do I unsubscribe from here?
Thank You,
Anthony
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Tom Lane wrote:
> See REINDEX.
>
Thanks.
-Tony
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
I've been going talking with the SGI technical support about some of the
errors I got when compiling Postgres 7.1.1 on SGI IRIX 6.5.12 with the
MIPSPro 7.3 C compiler. I've already mentioned that somehow the compiler
can't see the correct definition for strdup (I believe she thought that
it was du
Tom Lane wrote:
> is included in every Postgres source file (via c.h).
>
Yep. That's what I expected.
SGI technical support seems to think that the problem is with the POSIX flag.
" Have you defined any POSIX variables, such as -D_POSIX_SOURCE
or included pthread.h? When you enable POSI
I've been talking with SGI tech support about my problem with installing
Postgres 7.1.1 on the SGI (IRIX 6.5.12 using the MIPSPro 7.3 compiler).
Fortunately, one of my SGI's (an octane) built PG without any problem so
this is just academic now (but probably useful for others wanting to
install PG
Tom Lane wrote:
>
> That absolutely should NOT be necessary; there should be a proper
> extern declaration of strdup visible. Perhaps it should be added
> to include/port/irix5.h (cf port/nextstep.h).
>
> regards, tom lane
Just to make sure, I tried compiling on another
Tom Lane wrote:
> > #if _XOPEN4UX || defined(_BSD_TYPES) || defined(_BSD_COMPAT)
>
> Next thought is that maybe none of these control symbols are defined
> by default --- could you look into that possibility? Perhaps some
> compiler switches or #defines are needed to get IRIX to allow
> "struct
Tom Lane wrote:
> Evidently IRIX also considers strdup() to be nonstandard :-(
>
> It's hard to believe that SGI is quite this braindead. I think there is
> something broken about configure on your setup. Can't tell what from
> here --- suggest you call in some IRIX gurus.
>
Yep. So goes SGI.
Tom Lane wrote:
> "G. Anthony Reina" <[EMAIL PROTECTED]> writes:
> >> In postgres_ext.h, I changed:
> >>
> >> #define NAMEDATALEN 32
> >> to
> >> #define NAMEDATALEN 51
> >>
> >> Everything compiled and installed.
Tom Lane wrote:
> > cc-1070 cc: ERROR File = xact.c, Line = 696
> > The indicated type is incomplete.
>
> > struct timeval delay;
> >^
>
> Hm. Which system header file defines struct timeval on IRIX?
> I'd expect or , but maybe t
Sorry, I forgot to include that I'm compiling this on RedHat 6.2,
Pentium III with Postgres 7.1.1.
-Tony
> I'm not sure if this is still needed in postgres to define the length of
> a variable/table name.
>
> In postgres_ext.h, I changed:
>
> #define NAMEDATALEN 32
> to
> #define NAMEDATALEN 5
In addition to my RedHat 6.2 server, I'm installing Postgres 7.1.1 on an
SGI O2 (IRIX 6.5.10). The configure works, but the 'gmake all' fails
when it tries to compile 'xact.c':
cc-1521 cc: WARNING File = /usr/include/setjmp.h, Line = 26
A nonstandard preprocessing directive is used.
#ident "
I'm not sure if this is still needed in postgres to define the length of
a variable/table name.
In postgres_ext.h, I changed:
#define NAMEDATALEN 32
to
#define NAMEDATALEN 51
Everything compiled and installed. However, the initdb started up but
then just said that it failed.
I did a gmake clea
I see by the messages that 7.1.1 is in the final packaging. Anyone know
when it will be released?
-Tony
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [
Tom Lane wrote:
> Most likely, you removed the user that owned ro_ellipse. Create a
> user with the same usesysid shown as ro_ellipse's relowner, or else
> change the relowner field to point at an extant user.
>
> I believe 7.1's pg_dump copes with this sort of thing more gracefully...
>
>
I'm trying to use pg_dump to backup my tables one at a time from
Postgres 7.0.3 (I'll upgrade to 7.1 in a few weeks). I'm getting a
strange error that I've never encountered before.
The backup call is:pg_dump db01 -t cell | gzip > cell.backup.gz
The error is : failed sanity check, table ro_
Nathan Meyers wrote:
> Does the replication have to be reliable? Are you equipped to
> reconcile databases that have got out of sync, if not? Will the
> different labs ever try to update the same existing record, or
> insert conflicting (unique-key) records?
>
(1) Yes, of course. (2) Willing-
We use Postgres 7.0.3 to store data for our scientific research. We have
two other labs in St. Louis, MO and Tempe, AZ. I'd like to see if
there's a way for them to mirror our database. They would be able to
update our database when they received new results and we would be able
to update theirs.
Ken Hirsch wrote:
> So rtrim("center_out_opto", "_opto") returns
> "center_ou"
> because "u" is not in the set {o, p, t, _} but all the characters after it
> are.
> rtrim("center_out_opto", "pot_") will produce the same thing.
>
That seems like an odd definition (although as Tom points out,
I'm running Postgres 7.0.3 on a RedHat Linux 6.1. For some reason, rtrim
is giving me an incorrect result:
db01=# SELECT tablename FROM pg_tables WHERE tablename LIKE '%_opto' AND
tablename NOT LIKE 'pg%' ORDER BY tablename ASC ;
tablename
-
center_out_opto
circles_opto
e
Tom Lane wrote:
> You can't roll back a DROP TABLE under pre-7.1 releases (and 7.0 has
> a big fat warning notice to tell you so!). The physical table file
> is deleted immediately by the DROP, so rolling back the system catalog
> changes doesn't get you back to a working table.
>
> The only way
I was trying to add a column to a table and fill it but ran into a big
error. Apparently now Postgres can't open this table to vacuum or to
select although it does show up when I ask psql to describe the table
(i.e. db01=# /d center_out_analog_proc).
I'm using Postgres 7.0.3 on a PII/400 MHz with
Alfred,
Is there a tarbar with the updated files for the vacuum patch? Or,
is there some way to use the 'v.diff' file without the need to modify
the files by hand? I started changing the files by hand, but realized
that there is so much information that I'm bound to make a mistake in
the manu
I backed up my database from Postgres 6.5.3 and migrated to 7.0.2
several a few months ago. For some reason, data was lost in the
transition. I've finally pinned it down to the attached file (abridged
to point out the problem).
It looks like two things happened in the backup. First, when I move f
I've subscribed and un-subscribed to the HACKERS-DIGEST list several
times now. Each time I seem to be getting EVERY message sent to the list
rather than a DIGEST.
Can someone tell me if it is still possible to get a DIGEST of the list?
Is the list administrator aware of the problem?
Thanks.
-To
Tom Lane wrote:
> Your procedure was fine, but ALTER TABLE RENAME was mighty flaky in
> pre-7.0 releases. Even in 7.0, doing it inside a transaction block is
> asking for trouble (that's finally fixed for 7.1, thank goodness).
> I suspect you got bit by an ALTER bug. I'm not sure about the exac
the "DIGEST" to work on HACKERS. Seems to
be some problems with the majordomo.
Here's my original message:
Original Message
Subject: Weird backup file
Date: Fri, 17 Nov 2000 11:27:32 -0800
From: "G. Anthony Reina" <[EMAIL PROTECTED]>
Organization
I remember a post about 2 weeks back concerning a new patch that was to
be introduced as 7.0.3. I haven't seen any reference to this since then.
Is this still happening, or will the patch be part of 7.1?
-Tony Reina
54 matches
Mail list logo
