On Nov 19, 2013, at 8:14 AM, Robert Haas robertmh...@gmail.com wrote:
Everyone on this thread who thinks that there is Only One Right Way To
Do It should take a chill pill. There is, in fact, more than one
right way to do it.
You shoulda been a Perl hacker, Robert.
D
--
Sent via
On Nov 16, 2013, at 2:04 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
It’s still input and output as JSON, though.
Yes, because JavaScript Object Notation *is* a serialization format
(aka Notation) for converting JavaScript Objects to text format
and back :)
I still like JSONB best.
To me
On Nov 16, 2013, at 4:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Co-worker asked a question I could not answer: Why is IF NOT EXISTS not
supported by CREATE TABLE AS?
That's an even worse idea than plain CREATE IF NOT EXISTS (which was
put in over vocal objections from me and some other
On Nov 17, 2013, at 1:51 PM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
I'm wondering about just pushing hstore in core (even if technically
still an extension, install it by default, like we do for PLpgSQL), and
calling it a day.
It’s syntax is different than JSON, so one would need to
On Nov 17, 2013, at 2:26 PM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
It’s syntax is different than JSON, so one would need to convert to
and from JSON all the time to parse and serialize. PITA.
Oh I misremembered about that, I though it would take JSON as input
as-is and could be
On Nov 17, 2013, at 5:49 PM, Josh Berkus j...@agliodbs.com wrote:
Jstore isn't the worst name suggestion I've heard on this thread. The
reason I prefer JSONB though, is that a new user looking for a place to
put JSON data will clearly realize that JSON and JSONB are alternatives
and related
On Nov 17, 2013, at 8:19 PM, Andrew Dunstan and...@dunslane.net wrote:
I don't think any name that doesn't begin with json is acceptable. I could
live with jsonb. It has the merit of brevity, but maybe it's a tad too
close to json to be the right answer.
JSONFTW.
David
--
Sent via
Hackers,
Co-worker asked a question I could not answer: Why is IF NOT EXISTS not
supported by CREATE TABLE AS? Oversight, perhaps? Or maybe because one expects
the table to have the data from the SELECT statement? If the latter, maybe OR
REPLACE would be useful?
Best,
David
--
Sent via
On Nov 16, 2013, at 12:04 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
Then perhaps name the new binary json as jsob (JavaScript Object Binary)
or just jsobj (JavaScript Object) and keep current json for what it is,
namely
JavaScript Object Notation.
It’s still input and output as JSON,
On Nov 15, 2013, at 6:35 AM, Merlin Moncure mmonc...@gmail.com wrote:
Here are the options on the table:
1) convert existing json type to binary flavor (notwithstanding objections)
2) maintain side by side types, one representing binary, one text.
unfortunately, i think the text one must get
On Nov 15, 2013, at 12:37 PM, Andrew Dunstan and...@dunslane.net wrote:
It's making my head hurt, to be honest, and it sounds like a recipe for years
and years of inconsistencies and bugs.
I don't want to have two types, but I think I'd probably rather have two
clean types than this. I
On Nov 15, 2013, at 2:02 PM, Andrew Dunstan and...@dunslane.net wrote:
Yeah, it would be a total foot gun here I think.
I've come to the conclusion that the only possible solution is to have a
separate type. That's a bit sad, but there it is. The upside is that this
will make the work
On Nov 14, 2013, at 7:07 AM, Merlin Moncure mmonc...@gmail.com wrote:
This is exactly what needs to be done, full stop (how about: hstore).
It really comes down to this: changing the serialization behaviors
that have been in production for 2 releases (three if you count the
extension) is bad
On Nov 13, 2013, at 3:59 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
I remember strong voices in support of *not* normalising json, so that
things like
{a:1,a:true, a:b, a:none}
would go through the system unaltered, for claimed standard usage of
json as
processing instructions. That
On Nov 13, 2013, at 2:41 PM, Gavin Flower gavinflo...@archidevsys.co.nz wrote:
Would be possible to have a boolean, such as 'strict' - so that unique
ordered was only imposed when strict was TRUE? Alternately, separate
functions to allow the same choice?
It should be a pretty-printing
On Nov 13, 2013, at 4:45 PM, Andrew Dunstan and...@dunslane.net wrote:
It should be a pretty-printing function option, perhaps, but not core to the
type itself, IMO.
I don't in the least understand how it could be a pretty printing option. If
we move to a binary rep using the hstore stuff
On Oct 2, 2013, at 5:07 AM, Merlin Moncure mmonc...@gmail.com wrote:
Hrm. I get a seq scan for that query:
create index on try(upper_inf(irange));
explain select * from try where upper_inf(irange);
QUERY PLAN
On Oct 3, 2013, at 10:50 AM, Josh Berkus j...@agliodbs.com wrote:
But anyway, I still don’t understand why, if the function used to store the
value is immutable (as upper_inf() is), why Postgres doesn't do an index
scan. Is this something that could be improved in the planner?
Yes.
Hackers,
I was trying to figure out why a query was not doing an index-only scan on a
partial index, when Josh Berkus pointed to this issue, reported by Merlin
Moncure:
http://www.postgresql.org/message-id/CAHyXU0x1OGao48WajAfUsbXqkUDLf=_6ho6hlmb8dsfkwda...@mail.gmail.com
In short, the
On Oct 1, 2013, at 3:56 PM, Merlin Moncure mmonc...@gmail.com wrote:
I don't think it has anything to do with the conditional index -- it's
the functional based. For some reason postgres always wants to post
filter (note the filter step below):
postgres=# create index on
On Aug 29, 2013, at 1:11 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
I cannot to say what is good design for PL/pgSQL - only I feel so some
variant of RETURN statement is not good, because semantic is significantly
different. And I see a increasing inconsistency between a original ADA
On Aug 29, 2013, at 2:22 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
Still I don't think so correct solution is enabling a unbound SELECTs, but
correct is a fix a PERFORM and remove a necessity to use a PERFORM for call
of VOID functions.
Well, in this thread, I believe you are the
On Aug 29, 2013, at 2:41 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
I am thinking, so I propose a enough solution for you - when you use CTE for
execution of VOID function, then result vill be VOID set, what we can accept
as undefined result, and in this case a PERFORM should not be
On Aug 29, 2013, at 2:48 PM, Andres Freund and...@2ndquadrant.com wrote:
You have yet to supply any arguments which support this position.
I am not convinced that's enough of a reason, but the requirement to use
PERFORM for SELECTs that aren't stored anywhere actually has prevented
bugs for
On Aug 27, 2013, at 12:30 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
I disagree - Tom K. speaking about what he likes or dislikes (and about what
he didn't use) He forgot about strong points of implicit result or
interesting points. Clients usually has no problem with dynamic datasets
On Aug 27, 2013, at 1:36 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
I agree with David that we should use some new syntax to specify
return-results-directly-to-client, assuming we ever get any such
functionality. It seems like a pretty bad choice of default behavior,
which is
On Aug 27, 2013, at 3:10 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
CREATE PROCEDURE foo()
BEGIN
SELECT 1,2;
SELECT 2;
SELECT 3,4
END;
And is not strange expect a result
CALL foo()
1,2
2
3,4
Procedure is a script (batch) moved to server side for better performance
On Aug 23, 2013, at 8:51 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
it is about a personal taste - if you prefer more verbose or less verbose
languages.
I feeling a PERFORM usage as something special and you example is nice case,
where I am think so PERFORM is good for verbosity.
On Aug 21, 2013, at 4:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
test=# create cast (source as oid) without function;
ERROR: enum data types are not binary-compatible
The reason for that is you'd get randomly different results on another
installation. In this particular application, I
Hackers,
This seems reasonable:
david=# DO $$
david$# BEGIN
david$# WITH now AS (SELECT now())
david$# SELECT * from now;
david$# END;
david$# $$;
ERROR: query has no destination for result data
HINT: If you want to discard the results of a SELECT, use
Hi Pavel,
On Aug 20, 2013, at 2:11 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
david=# DO $$
david$# BEGIN
david$# WITH now AS (SELECT now())
david$# PERFORM * from now;
david$# END;
david$# $$;
ERROR: syntax error at or near PERFORM
LINE 4:
On Aug 20, 2013, at 2:24 PM, Marko Tiikkaja ma...@joh.to wrote:
postgres=# DO $$
BEGIN
PERFORM * FROM (WITH now AS (SELECT now())
SELECT * from now) x;
END;
$$;
DO
.. which doesn't work if you want to use table-modifying CTEs.
Which, in fact, is exactly my use case (though not
On Aug 20, 2013, at 2:31 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
but it works
postgres=# do $$begin with x as (select 10) insert into omega select * from
x; end;$$;
DO
But this does not:
david=# DO $$
david$# BEGIN
david$# PERFORM * FROM (
david$# WITH inserted AS (
On Aug 20, 2013, at 2:41 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
yes, in this context you should not use a PERFORM
PL/pgSQL protect you before useless queries - so you can use a CTE without
returned result directly or CTE with result via PERFORM statement (and in
this case it
On Aug 20, 2013, at 2:44 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
I think the way forward is to remove the restriction such that data
returning queries must be PERFORM'd
I disagree, current rule has sense.
Perhaps a DECLARE FUNCTION attribute that turns off the functionality, then?
On Aug 20, 2013, at 2:53 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
I am passing the values returned from a CTE to a call to pg_notify(). I do
not care to collect the output of pg_notify(), which returns VOID.
it is little bit different issue - PL/pgSQL doesn't check if returned type
On Aug 20, 2013, at 3:05 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
When you would to ignore result, then you should to use a PERFORM - actually,
it is limited now and should be fixed. Have no problem with it.
Glad to have you on board. :-)
I don't would to enable a free unbound
On Aug 20, 2013, at 3:18 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
can you show some examples, please
This is not dissimilar to what I am actually doing:
CREATE TABLE foo (id SERIAL PRIMARY KEY, name TEXT);
CREATE OR REPLACE FUNCTION shipit (
VARIADIC things TEXT[]
On Aug 20, 2013, at 3:38 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
pg_notify returns void, so there are no necessary casting to void
so enhanced check - so all returned columns are void should be enough
What if I call another function I wrote myself that returns an INT, but I do
not
Hackers,
I am trying to do something like this:
CREATE TYPE source AS ENUM(
'fred', 'wilma', 'barney', 'betty'
);
CREATE EXTENSION btree_gist;
CREATE TABLE things (
source source NOT NULL,
within tstzrange NOT NULL,
EXCLUDE USING gist (source
On Aug 20, 2013, at 6:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
You need more parentheses -- (source::text) would've worked.
Alas, no, same problem as for CAST():
ERROR: functions in index expression must be marked IMMUTABLE
No problem, I can use CAST(), right? So I try:
EXCLUDE
On Jul 23, 2013, at 6:24 PM, David E. Wheeler da...@justatheory.com wrote:
I kind of suspect not, since this fails:
david=# select '12:24:53 654'::time;
ERROR: invalid input syntax for type time: 12:24:53 654
LINE 1: select '12:24:53 654'::time;
^
I would have guessed
On Jul 23, 2013, at 1:17 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Does that create any ambiguities against formats we already support?
I'm worried about examples like this one:
select 'monday, july 22, 22:30 2013'::timestamptz;
timestamptz
2013-07-22
Hackers,
According to [Wikipedia](https://en.wikipedia.org/wiki/ISO_8601#Times):
Decimal fractions may also be added to any of the three time elements. A
decimal mark, either a comma or a dot (without any preference as stated in
resolution 10 of the 22nd General Conference CGPM in 2003,[11]
On Jul 8, 2013, at 7:44 AM, ivan babrou ibob...@gmail.com wrote:
Can you tell me why having ability to specify more accurate connect
timeout is a bad idea?
Nobody answered my question yet.
From an earlier post by Tom:
What exactly is the use case for that? It seems like extra
On Jun 16, 2013, at 9:20 AM, Cédric Villemain ced...@2ndquadrant.com wrote:
Then instead of the above you'd just be able to say something like
MODULETEST = test
or REGRESSDIR ?
Yeah, that sounds perfect.
Also I suggest to remove the need to set REGRESS at all, and default to all
On Jun 15, 2013, at 4:12 AM, Andrew Dunstan and...@dunslane.net wrote:
REGRESS_OPTS = --inputdir=test --outputdir=test \
--load-extension=$(EXTENSION)
...
override pg_regress_clean_files = test/results/
test/regression.diffs test/regression.out tmp_check/ log/
That
On Jun 12, 2013, at 8:16 PM, Peter Eisentraut pete...@gmx.net wrote:
This has served no purpose except to
1. take up space
2. confuse users
3. produce broken external extension modules that take contrib as an example
4. break builds of PostgreSQL when users try to fix 3. by exporting
On Jun 12, 2013, at 8:00 PM, Brendan Jurd dire...@gmail.com wrote:
array_dims - Returns the dimensions of the array, unless it is empty
in which case NULL.
array_proper_dims - Returns the dimensions of the array.
array_ndims - Returns the number of dimension, unless it is empty in
which case
On Jun 11, 2013, at 3:09 PM, Brendan Jurd dire...@gmail.com wrote:
There have been attempts to add a cardinality function in the past, as
it is required by the SQL spec, but these attempts have stalled when
trying to decide how it should handle multidim arrays. Having it
return the length of
On Jun 3, 2013, at 7:31 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Hah. That leads to
http://perl5.git.perl.org/perl.git/commitdiff/451f421
in which it's said What happens is that eval tacks \n; on to the end
of the string if it does not already end with a semicolon.
So we could likely hide
On May 29, 2013, at 10:48 AM, Fabien COELHO coe...@cri.ensmp.fr wrote:
If you do it, having uint1 (1 byte) would be nice as well.
There is a signed 1byte int on PGXN, FWIW:
http://pgxn.org/extension/tinyint
Best,
David
--
Sent via pgsql-hackers mailing list
On May 16, 2013, at 7:02 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
I find this feature quite useful, but I understand that my use case
may be quite unique.
Just to say that I too find what you've done quite useful. Please add
your patch to the next commit fest for consideration in
On Apr 4, 2013, at 2:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think this should be addressed in extend.sgml not only on the CREATE
EXTENSION reference page. After thinking awhile I came up with the
attached wording. Further wordsmithing anyone?
Works for me, though I think it would be
On Apr 4, 2013, at 5:16 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
David E. Wheeler da...@justatheory.com writes:
+Note that only the extension objects will be placed into the named
+schema; the extension itself is a database-global object.
I think you're patching
On Apr 3, 2013, at 2:37 AM, Albe Laurenz laurenz.a...@wien.gv.at wrote:
I'd expect one of the CREATE EXTENSION commands to succeed
and the others to block until the transaction is committed,
then to fail with 'extension oracle_fdw already exists'.
If that is what happens, it's what I'd
On Apr 3, 2013, at 9:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fortran ... Basic ... actually I'd have thought that zero was a
minority position. Fashions change I guess.
I say we turn the default lower bound up to 11.
David
--
Sent via pgsql-hackers mailing list
On Apr 3, 2013, at 11:41 AM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Oh, they are not unique per-schema? I guess they are global to the database
but then their objects are in the specified schema, then.
Right -- an extension is not considered to live within a schema, they
are
On Apr 2, 2013, at 8:03 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Are there any widely known non-built-in cases besides citext?
Well, indxpath.c knows about text LIKE and network subset operators,
and it would be nice if it knew how to do the same type of optimization
for range inclusion, ie
On Apr 2, 2013, at 10:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Is this knowledge encapsulated in a to-do?
I added an item to the Indexes section of the TODO page.
Great, thanks.
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Hackers,
I am working on scripts to copy data from Oracle via oracle_fdw. They each do
something like this:
CREATE SCHEMA migrate_stuff;
SET search_path TO migrate_stuff,public;
CREATE EXTENSION oracle_fdw SCHEMA migrate_rules;
CREATE SERVER oracle_stuff FOREIGN DATA WRAPPER
On Apr 1, 2013, at 4:59 PM, Robert Haas robertmh...@gmail.com wrote:
I think the only people for whom nothing will break are the people who
aren't using arrays in the first place. Anyone who is is likely to
have dependencies on the way array_lower/upper work today.
Well, what if we add new
On Mar 20, 2013, at 1:45 AM, David E. Wheeler da...@kineticode.com wrote:
Is there currently any way to create an index that can be used to speed up
searches like the one above?
If not, do you have any idea how it might be implemented? Perhaps I could
give it a try myself.
Thank you
On Mar 20, 2013, at 4:45 PM, Brendan Jurd dire...@gmail.com wrote:
I submit a patch to rectify the weird and confusing quirk of Postgres
to use zero dimensions to signify an empty array.
Epic. Thank you. I’m very glad now that I complained about this (again)!
Best,
David
--
Sent via
On Mar 17, 2013, at 6:35 AM, Thorbjørn Weidemann thorbjo...@weidemann.name
wrote:
Hi David,
I found your email-address on
http://www.postgresql.org/docs/9.2/static/citext.html. I hope it's ok to
contact you this way.
I would like to thank you for taking the time to make citext available
On Mar 16, 2013, at 11:19 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Perhaps not. I think for most uses, a 1-D zero-length array would be
just as good. I guess what I'd want to know is whether we also need
to support higher-dimensional zero-size arrays, and if so, what does
the I/O syntax for
Hackers,
This surprised me:
david=# select array_length('{}'::text[], 1);
array_length
--
[null]
I had expecte dit to retur 0. I might expect NULL for a NULL param, but not one
that's defined but has no elements.
Best,
David
--
Sent via pgsql-hackers
On Mar 15, 2013, at 3:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The thing is that that syntax creates an array of zero dimensions,
not one that has 1 dimension and zero elements. So 0 would be
incorrect.
Our handling of empty arrays leaves something to be desired, I agree,
but making it
On Mar 15, 2013, at 3:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Oh. Is there a way to declare an empty 1-dimension array?
Doesn't look like it:
regression=# select '[1:0]={}'::text[];
ERROR: upper bound cannot be less than lower bound
LINE 1: select '[1:0]={}'::text[];
^
On Mar 13, 2013, at 5:17 AM, Robert Haas robertmh...@gmail.com wrote:
What I think is tricky here is that there's more than one way to
conceptualize what the JSON data type really is. Is it a key-value
store of sorts, or just a way to store text values that meet certain
minimalist syntactic
On Mar 13, 2013, at 10:45 AM, Andrew Dunstan and...@dunslane.net wrote:
If someone wants functions to enforce a stricter validity check (e.g. via a
check constraint on a domain), or to convert json to a canonical version
which strips out prior keys of the same name and their associated
On Mar 13, 2013, at 10:59 AM, Andrew Dunstan and...@dunslane.net wrote:
And my first cut at it won’t descend into sub-objects.
The you wouldn't be doing it right. The whole thing about a recursive descent
parser is that it's, well, recursive.
Right, but it would serve my immediate needs.
On Mar 8, 2013, at 1:01 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
If it does not meet these semantic constraints, then it is not
really JSON - it is merely JSON-like.
this sounds very much like MySQLs decision to support timestamp
-00-00 00:00 - syntactically correct, but
On Mar 8, 2013, at 1:21 PM, Andrew Dunstan and...@dunslane.net wrote:
Here's what rfc2119 says about that wording:
4. SHOULD NOT This phrase, or the phrase NOT RECOMMENDED mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or
On Mar 7, 2013, at 7:55 AM, Kevin Grittner kgri...@ymail.com wrote:
If the answer to both those questions is “yes,” I think the term
should remain “table,” with a few mentions that the term includes
materialized views (and excludes foreign tables).
And if the answers are not exactly and
This behavior surprised me a bit:
david=# select '{foo: 1, foo: 2}'::json;
json
--
{foo: 1, foo: 2}
I had expected something more like this:
david=# select '{foo: 1, foo: 2}'::json;
json
{foo: 2}
This
On Mar 6, 2013, at 1:51 PM, Kevin Grittner kgri...@ymail.com wrote:
I also think that something should be done about the documentation
for indexes. Right now that always refers to a table. It would
clearly be awkward to change that to table or materialized view
everywhere. I wonder if most
Hello ActiveStaters,
I see that the DBD::Pg build always fails:
http://code.activestate.com/ppm/DBD-Pg/
I'm sure this is because PostgreSQL is not installed on any of the PPM build
boxes (smokers?). DBD::mysql, on the other hand, builds fine (most of the time):
On Feb 26, 2013, at 3:07 PM, Jan Dubois j...@activestate.com wrote:
Hello ActiveStaters,
The commonly used term is actually Activator. :)
Got it!
Yes, that is one reason. We then need to apply several patches to build
things correctly though (to statically link the client libs, deal with
On Feb 22, 2013, at 12:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah, you did:
http://www.postgresql.org/message-id/62fdd311-1afc-4296-95d8-5751d1407...@justatheory.com
I still think it's incumbent on OSSP to fix this, not us. Or if
they've gone dead, maybe we need to start looking for
On Feb 22, 2013, at 9:37 AM, Robert Haas robertmh...@gmail.com wrote:
What I think is NOT tolerable is choosing a set of short but arbitrary
names which are different from anything that we have now and
pretending that we'll want to use those again for the next data type
that comes along.
While building 9.2.3 on OS X 10.8.2 today:
checking ossp/uuid.h usability... no
checking ossp/uuid.h presence... yes
configure: WARNING: ossp/uuid.h: present but cannot be compiled
configure: WARNING: ossp/uuid.h: check for missing prerequisite headers?
configure: WARNING: ossp/uuid.h: see
On Feb 19, 2013, at 6:11 AM, Petr Jelinek pjmo...@pjmodos.net wrote:
some of the points you raise are valid, but in my (minority) opinion
overloading creates more problems than it solves. You're not going to
convince me that get() is *ever* a good name for a function - you might as
well call
On Feb 17, 2013, at 6:33 AM, Andrew Dunstan and...@dunslane.net wrote:
No, then we don't have a variadic version. You are going to have to accept
that we can't make one function name cover all of this.
Well, for me, I would rather specify an array than call a function with a
different name.
On Feb 16, 2013, at 8:57 AM, Andrew Dunstan and...@dunslane.net wrote:
I have had a look at doing something like this with the json_get functions.
The trouble is that the best way to do it is to have json_get take variadic
any, but then string literals come in as unknown rather than as text,
On Feb 16, 2013, at 12:47 PM, Andrew Dunstan and...@dunslane.net wrote:
To answer David's point, there is no point in having both
get(json,text)
get(json, variadic text[])
since the second can encompass the first, and having both would make calls
ambiguous.
Oh. Well then how
On Feb 15, 2013, at 9:25 AM, Robert Haas robertmh...@gmail.com wrote:
I realize I'm in the minority here, but -1 from me on all of this.
Should we also rename xml_is_well_formed() to just is_well_formed()?
That would be nice, but I think that ship done sunk.
string_agg() to agg()?
Would
On Feb 13, 2013, at 8:36 AM, Andrew Dunstan and...@dunslane.net wrote:
I don't have any problem getting rid of the json_ prefixes, except for
json_agg which I think should keep it (c.f. string_agg, array_agg).
I think that's an unfortunately naming forced on us by the SQL standard, and it
On Feb 13, 2013, at 9:31 AM, Andrew Dunstan and...@dunslane.net wrote:
I don’t love those, but if we want to follow precedent…
Ditto. I think we're a bit late to be adding functionality.
Well, how about having just keys() and vals() return arrays? Then one can just
wrap them in unnest() to
Hello Hackers,
If you dislike bike-shedding (and who does?), delete this email and the ensuing
thread right now. You have been warned!
I have been playing with Andrew’s JSON enhancements and really enjoying them. I
am already using them in code I’m developing for production deployment in a
On Feb 12, 2013, at 2:01 PM, Josh Berkus j...@agliodbs.com wrote:
Given that row() is already a type-agnostic function, and RECORD is a
stored procedure return meta-type, I think the above names would be a
mistake. I'd suggest instead:
json_to_record() and json_to_recordset()
or:
On Feb 12, 2013, at 8:00 PM, Merlin Moncure mmonc...@gmail.com wrote:
+1 for removing that where possible. We generally have avoided such
names at SQL level. (The C-level function names need such prefixes to
be unique, but the SQL names don't.)
In the cases where one or more arguments are
Hackers,
While playing with Andrew’s JSON enhancements, I noticed this:
david=# select * From json_each_as_text('{baz: null}'::json);
key | value
-+---
baz | null
It is returning 'null'::text there, not NULL::text. I had expected the latter,
because otherwise it's
On Feb 4, 2013, at 8:10 AM, Andrew Dunstan and...@dunslane.net wrote:
My suggestion would be ~ and ~. I know David Wheeler didn't like that on
the ground that some fonts elevate ~ rather than aligning it in the middle as
most monospaced fonts do, but I'm tempted just to say then use a
On Jan 31, 2013, at 2:20 PM, Andrew Dunstan and...@dunslane.net wrote:
I'm happy to take opinions about this, and I expected some bikeshedding, but
your reaction is contrary to everything others have told me. Mostly they love
the operators.
I guess that '~' and '~' would work as well as
On Jan 31, 2013, at 4:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Ada or no, its use in plpgsql would render that a seriously bad idea.
I assumed that its use in function params would be the main reason not to use
it.
David
--
Sent via pgsql-hackers mailing list
On Jan 15, 2013, at 12:17 PM, Andrew Dunstan and...@dunslane.net wrote:
I doubt I'm very representative either. People like David Wheeler, Taras
Mitran, Joe Van Dyk, and the Heroku guys would be better people to ask than
me. I'm quite prepared to change it if that's the consensus.
They’re
Hackers,
I'm trying to write a query to give me a list of the columns and/or expressions
in an index. For example, given this table:
david=# \d foo
Table public.foo
Column | Type| Modifiers
-+---+---
id | integer |
bar_ids | integer[] |
On Jan 10, 2013, at 2:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Is there some way to only get the relevant index expression from indexprs,
rather than the whole expression?
pg_get_indexdef() is your friend. You really, really don't want to
write any client-side code that inspects indexprs
On Nov 26, 2012, at 11:12 AM, Peter Eisentraut pete...@gmx.net wrote:
Although my intuition would be [], the existing concatenation-like
aggregates return null for no input rows, so this probably ought to be
consistent with those.
This annoys me at times, but I wrap such calls in COALESCE()
101 - 200 of 1565 matches
Mail list logo
