Is there a good reason for this thread being copied to the advocacy list? It
seems to me just on topic for hackers. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
something only allowed for major releases and not minor ones which were just
supposed to be security and bug fixes.
So what changed that it is added in 9.3.x after all?
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On 2013.08.27 7:57 PM, Tom Lane wrote:
Darren Duncan writes:
I have a proposal.
Assuming we decide to do away with RULEs,
You lost me already.
If we had replacement functionality for everything that can be done with
rules, we could start to think about when we might begin to tell people
Would that not work? -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ll try and answer as time permits.
-- Darren Duncan
On 2013.05.11 9:27 AM, Tom Lane wrote:
David Fetter writes:
On Sat, May 11, 2013 at 11:17:03AM -0400, Robert Haas wrote:
Some kind of extendable parser would be awesome. It would need to tie
into the rewriter also.
No, I don't have a c
On 2013.05.09 11:22 AM, Alvaro Herrera wrote:
Darren Duncan wrote:
On 2013.05.09 10:40 AM, Pavel Stehule wrote:
I am writing a article about 9.3. I found so event trigger functions is not
complete. We have only pg_event_trigger_dropped_objects() function. It looks
really strange and asymmetric
. Are drops the main expected use case for the feature,
rather than "tell me when something happened"? -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2013.03.26 1:40 AM, Albe Laurenz wrote:
Darren Duncan wrote:
So, determining if 2 rows are the same involves an iteration of dyadic logical
AND over the predicates for each column comparison. Now logical AND has an
identity value, which is TRUE, because "TRUE AND p" (and &
On 2013.03.25 6:03 PM, Darren Duncan wrote:
On 2013.03.25 5:55 PM, Craig Ringer wrote:
On 03/25/2013 10:28 PM, Tom Lane wrote:
Yeah, they are, because things break when they're set wrong.
They also make debugging and support harder; you need to get an
ever-growing list of GUC values fro
7;t
any actual loss of functionality, but users might have to change their code to
do it "the one true way", that would seem a good thing. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2013.03.25 1:17 AM, Albe Laurenz wrote:
Darren Duncan wrote:
From my usage and
http://www.postgresql.org/docs/9.2/interactive/sql-createtable.html I see that
Postgres requires constraints like unique (and primary) keys, and foreign keys,
to range over at least 1 attribute/column.
I
can
exist in order to support implementation matters of foreign keys that require
their targets to be unique.)
How much work would it be to support this? But also important, does anyone
either agree it should be supported or does anyone want to counter-argue that it
shouldn't be supp
se that to
represent some things in a more natural manner than a tabular format? JSON is
designed to be machine-parseable, and some objects such as routine definitions
are naturally trees of arbitrary depth. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
implicitly stringify. But I can also accept implicit
stringification / language behavior changes if it is a lexical/temporary effect
that the same user is still explicitly turning on.
-- Darren Duncan
Jeff Davis wrote:
On Mon, 2012-12-10 at 14:07 -0500, Robert Haas wrote:
And we not only don&#
Dimitri Fontaine wrote:
Darren Duncan writes:
So, I'm partly proposing a specific narrow new feature, "TRUNCATE FOR EACH
ROW"
Kevin has been proposing that we consider an alternative approach in
some other cases that I think would work better for you, too. Namely, to
have ac
vileges.
Thank you.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
any
triggers, as if it were just a syntactic shorthand. Or alternately/also provide
extra syntax to TRUNCATE itself where one can specify which behavior to have,
and both options can be given explicitly to override any config option.
-- Darren Duncan
--
Sent via pgsql-hackers m
John R Pierce wrote:
On 10/12/12 9:00 PM, Darren Duncan wrote:
And now we're migrating to Red Hat for the production launch, using
the http://www.postgresql.org/download/linux/redhat/ packages for
Postgres 9.1, and these do *not* include the SSL.
hmm? I'm using the 9.1 for CentO
have used it.
(Though all database access would be over a private server-server network, so
the situation isn't as bad as going over the public internet.)
How much trouble would it be to make the
http://www.postgresql.org/download/linux/redhat/ packages include SSL?
-- Darren Dunc
, and it will alert users right where they're
most likely to look, the RULEs documentation, without any undue delay.
How does that sound?
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
delay #1 is if we aren't sure we're going to go ahead
with it, and give a few months to think about it before announcing this major
thing suddenly. Waiting until 9.3 just to make an announcement is silly.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
arly, all the converting operators between other types
and JSON would be with #2 only, and producing #1 must go through #2.
So call #1 say JSON_source and #2 say JSON_model, or JSON_text and JSON
respectively.
That's how I think it should work.
-- Darren Duncan
--
Sent via pgsql-
That sounds like a good change to me. -- Darren Duncan
Craig Ringer wrote:
Hi all
I'm seeing lots of confusion from people about why:
REVOKE CONNECT ON DATABASE foo FROM someuser;
doesn't stop them connecting. Users seem to struggle to understand that:
- There's a d
DBMS being given only
the view-defining SELECT, where possible. -- Darren Duncan
Dean Rasheed wrote:
I've been playing around with the idea of supporting automatically
updatable views, and I have a working proof of concept. I've taken a
different approach than the previous attempts to
able, so it has a corresponding type like the regular
table/relation-typed variables in the database.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
have different interpretations in the
transform.
Ideally the feature would also work not only for interfacing with PLs but also
with client languages, since conceptually its alike but just differing on who
calls who.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
ero tuples.
Jeff, I get the impression your proposal is partly about helping performance by
supporting this internally, rather than one just defining it as a SQL function,
am I right?
-- Darren Duncan
Jeff Davis wrote:
I hope this is not an inappropriate time for 9.3 discussions. The fli
idely used, and if we have * anyway, then the exclusion
proposal is just an enhancement to that. So there is no reason to reject the
complementary columns feature because of the problems with "select *"; you might
as well argue to get rid of "select *". -- Darren Duncan
--
tion syntax to give the complementary projection,
like with "r{x,y}" vs "r{all but x,y}".
Also, a more tenuous connection, Larry Wall likes "but" as logical modifier.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
nk that would make the feature even more valuable and more
syntactically clean than I had previously thought.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
Darren Duncan writes:
The real question to ask ourselves is, if Eric Ridge is willing to do all the
work to implement this feature, and the code quality is up to the community
standards and doesn't break anything else, then will the code be accepted?
It's entirel
David Wilson wrote:
On Sun, Oct 30, 2011 at 1:10 AM, Darren Duncan wrote:
The SQL level is exactly the correct and proper place to do this.
Its all about mathematical parity. That is the primary reason to do it.
- "SELECT *" gives you a whole set.
- "SELECT foo, bar" g
and its another thing to argue whether that feature is
harmful enough to reject a free working implementation (of otherwise conforming
code quality) from someone who has already gone to the trouble to implement it.
Eric, if you want to implement this, I say more power to you, and I will use it.
Pavel Stehule wrote:
2011/10/30 Darren Duncan :
I agree that this feature would be quite useful and should be included in
SQL. The exact syntax is less of an issue, but just the ability to cleanly
say "select all columns except for these". I have in fact argued for the
same feature i
t()" or
"except" or "not in". One should be able to do complements not only of rows but
of columns too. Basic good language design.
-- Darren Duncan
Eric Ridge wrote:
Would y'all accept a patch that extended the "SELECT *" syntax to let
you list fields
e for a day or so if they need more time? It's certainly less
critical than the older branches.
I would prefer that all branches have synchronized patch releases as they seem
to have had in the past, and that the latest production is included, 9.1.1 in
this case, even if its change set is mor
ecifying a number of intended significant
design improvements/simplifications to the spec proper, though much of this is
hashed out in the laundry list TODO_DRAFT file in github.
-- Darren Duncan
Joe Abbate wrote:
On 09/19/2011 12:40 PM, Christopher Browne wrote:
On Mon, Sep 19, 2011 at 12
really glad it was found now. --
Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I will put my support for David Johnston's proposal, in principle, though minor
details of syntax could be changed if using "!" conflicts with something. --
Darren Duncan
David Johnston wrote:
On Mon, Jul 11, 2011 at 10:12 AM, Florian Pflug wrote:
On Jul11, 2011, at 07:08
oes not make the database
any less relational, because the above definition and any others still hold.
The "less relational" argument above is a red herring or distraction. One can
argue against namespace nesting just fine without saying that.
-- Darren Duncan
--
Sent via pgsql-
Jeff Davis wrote:
On Fri, 2011-07-08 at 23:39 -0700, Darren Duncan wrote:
What if you used the context of the calling code and resolve in favor of
whatever match is closest to it? The problem is related to general-purpose
programming languages.
Basically start looking in the lexical context
ld also come up with some "relative name" syntax such as filesystems
support with their ../ and such, but that's further from standard SQL.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
h about it to make some useful contributions in the meantime. How much or
what I already know may not always come across well. If this bothers people
then I can make more of an effort to reduce my input until I have more solid
things to back them up.
-- Darren Duncan
--
Sent via pgsql-hacke
Jeff Davis wrote:
On Thu, 2011-07-07 at 23:21 -0700, Darren Duncan wrote:
I think an even better way to support this is would be based on Postgres having
support for directly using multiple databases within the same SQL session at
once, as if namespaces were another level deep, the first level
Jeff Davis wrote:
On Thu, 2011-07-07 at 20:56 -0700, Darren Duncan wrote:
When you create a temporary table, PostgreSQL needs to add rows in
pg_class, pg_attribute, and probably other system catalogs. So there are
writes, which aren't possible in a read-only transaction. Hence the
error. A
g 8.4+ has named subqueries which handle a lot of cases
where temp tables would otherwise be used, I would certainly expect those to
work when you're dealing with a readonly database.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
Jeff Davis wrote:
On Sun, 2011-06-26 at 22:29 -0700, Darren Duncan wrote:
Tom Lane wrote:
Darren Duncan writes:
I believe that the best general solution here is for every ordered base type to
just have a single total order, which is always used with that type in any
generic order-sensitive
Jeff Davis wrote:
On Sun, 2011-06-26 at 00:57 -0700, Darren Duncan wrote:
I believe that the best general solution here is for every ordered base type to
just have a single total order, which is always used with that type in any
generic order-sensitive operation, including any ranges defined
Tom Lane wrote:
Darren Duncan writes:
I believe that the best general solution here is for every ordered base type to
just have a single total order, which is always used with that type in any
generic order-sensitive operation, including any ranges defined over it, or any
ORDER BY or any
nd hence you'd rarely see any 'foo'::text__en_US
for example. You'd more likely see the less common var::text__en_US or such.
So that's my position, CREATE TYPE on the regular types or the like is the best
solution, and anything else is an inferior solution.
Such a d
Florian Pflug wrote:
On Jun20, 2011, at 20:58 , Tom Lane wrote:
Darren Duncan writes:
I still think that the most elegant solution is for stuff like collation to just
be built-in to the base types that the range is ranging over, meaning we have a
separate text base type for each text
to text/etc types is the root of the problem. The
range-specific stuff can remain ANYELEMENT and no special-casing is required.
Also, besides range constructors, a generic membership test like "value in
range" is polymorphic. -- Darren Duncan
--
Sent via pgsql-hackers mailing list
ons on those
values (such as sorting) should be considered part of the data type of those values.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Jeff Davis wrote:
On Mon, 2011-06-06 at 14:42 -0700, Darren Duncan wrote:
Can Pg be changed to support "." in operator names as long as they don't just
appear by themselves? What would this break to do so?
Someone else would have to comment on that. My feeling is that
r finds that 2 operands to the generic "=" (equality test) operator
result in TRUE, then the program should feel free to replace all occurrences of
one operand in the program with occurrences of the other, for optimization,
because generic "=" returning TRUE means one is just
Jeff Davis wrote:
On Sun, 2011-06-05 at 21:51 -0700, Darren Duncan wrote:
Jeff Davis wrote:
I'd like to take another look at Range Types and whether part of it
should be an extension. Some of these issues relate to extensions in
general, not just range types.
First of all, what ar
Pavel Stehule wrote:
2011/6/6 Darren Duncan :
Jeff Davis wrote:
I'd like to take another look at Range Types and whether part of it
should be an extension. Some of these issues relate to extensions in
general, not just range types.
First of all, what are the advantages to being in core?
general results of range union operations.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas wrote:
On Tue, May 17, 2011 at 4:45 PM, Joshua D. Drake wrote:
On 05/17/2011 01:31 PM, Darren Duncan wrote:
I have missed it if this was discussed before but ...
Would now be a good time to start deprecating the contrib/ directory as
a way to distribute Pg add-ons, with favor
overlap period where people could get the legacy add-ons either way.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
o2bar() function instead. You still get code with the same level of
terseness and that is just as easy to read and understand, and there is no
question of semantics. Also, that solution works right now. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
Jaime Casanova wrote:
On Sat, May 14, 2011 at 8:42 PM, Darren Duncan wrote:
First of all, what if "cast(timestamp as int)" was already defined? Which
cast then would you expect to be invoked here?
'1800-01-01 00:00:00'::int
i will expect an error in that case... what y
Darren Duncan wrote:
I think it would be best that the generic cast syntax only be useable
for casts defined on the base type, and if you want a domain-specific
one you should use the function syntax such as your datetime2int().
That way it is easier for users to predict what behavior will
asier for users to predict what behavior will occur, and
implementation will be easier too.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ld be supported in tables too.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas wrote:
On Wed, May 11, 2011 at 11:43 AM, Joseph Adams
wrote:
On Tue, May 10, 2011 at 5:19 PM, Darren Duncan wrote:
Examples of open union types could be number, which all the numeric types
compose, and so you can know say that you can use the generic numeric
operators on values
Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of mar may 10 16:21:36 -0400 2011:
Darren Duncan wrote:
To follow-up, an additional feature that would be useful and resembles union
types is the variant where you could declare a union type first and then
separately other
ncept from what we're otherwise
talking about as being union types. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Ns; eg, I would expect the 4th line above to
just work, because the system knows the type of CURRENT_TIMESTAMP and it knows
that this is a member of the union type of myunion. I see a UNION type as being
like a DOMAIN type in reverse.
-- Darren Duncan
--
Sent via pgsql-hackers mailing lis
just a type constraint and an optimization.
Of course, when we know the type of a column/etc isn't going to be VARIANT or
some other union type, then a simple optimization allows us to just store the
value and have its type provided by context rather than the struct.
-- Darren Duncan
--
a
regular transaction or savepoint or whatever is specific to a process/auto.
Has anyone else thought of the DBMS as operating system analogy? I don't recall
specifically reading this anywhere, but expect the thought may be common.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list
should be
deterministic. But that ship has sailed and I'm not going to argue for any
changes to functions.)
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas wrote:
I am halfway tempted to say that we need to invent our own procedural
language that is designed not for compatibility with the SQL standard
or Oracle, but for non-crappiness.
I'm way ahead of you on that one. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (
foo can where the latter
is a case-insensitive identifier.
As for the SQL standard for bind parameters, as I recall they use :foo and so
:"foo" would be the sensitive more general case of that.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
replacement.
In any event, QUEL was somewhat similar to SQL.
-- Darren Duncan
Rajasekhar Yakkali wrote:
"Following a great deal of discussion, I'm pleased to announce that the
PostgreSQL Core team has decided that the major theme for the 9.1
release, due in 2011, will be 'NoSQL'.
r substituted for some parameter or there be other grief as I seem to
recall having in 8.4. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Pavel Stehule wrote:
2011/3/26 Darren Duncan :
I mention 2 possible solutions here, both which involve syntax alterations,
each between the -- lines. I personally like the second/lower
option more.
-1
this is not based on any pattern on SQL. It's not simple, and it
introd
t;.
A Perl 6 analogy being something like:
$mytbl.map:{ .mycol + $myvar * $myparam }
aka:
$mytbl.map:{ $_.mycol + $myvar * $myparam }
--
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ld always be consistent on
transaction boundaries, at the very least, if not on statement boundaries.
As to whether B's failure happens when it tries to commit or happens earlier,
based on visibility issues with A's changes, doesn't matter to me so much (do
what works best for you/o
, meaning ones that can
work with any relations like built-ins can, and the ability to iterate over
record fields, or at least introspect a relation to see what fields it has, is a
good foundation to support this. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
Daniel Farina wrote:
On Sat, Nov 13, 2010 at 7:54 PM, Darren Duncan wrote:
You don't have to kludge things by implementing arrays as blobs for example;
you can implement them as relations instead. Geospatial types can just be
tuples. Arrays of structured types can just be relations wi
there was/is a lot I still didn't/don't know about
Postgres, I have found that as I use and learn Postgres, I'm finding frequently
that how Postgres does things is similar and compatible to how I independently
came up with Muldis D's design; I'm finding more similariti
f my identifiers as being case-sensitive. Knowing that
Pg treats non-delimited identifiers as being lowercase, I write undelimited when
the identifier is entirely lowercase, and I delimit ones that have any
uppercase. And by doing this consistently everything works correctly. Since
most of my ident
or ?) etc was so that SQL could
be written in EBCDIC which natively lacks some of the bracketing characters that
ASCII has. Hence, such is an alternative way to spell either { } or [ ] (I
forget which).
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
, loosely speaking.
The association of a multiset-typed attribute of a table with said table is like
the association of a child and parent table in a many-to-one.
So reuse your structure for tables to hold multisets.
-- Darren Duncan
Itagaki Takahiro wrote:
Postgres supports ARRAY data types well
s data fields in their runtime-accessible objects.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ing would only appear in the catalog
if specially formatted, which for now could just mean taking end-of-line comments.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
QL updates go to postgresql.conf.auto, which consists only of
"setting = value" in alphabetical order.
(d) We document that settings which are changed manually in
postgresql.conf will override postgresql.conf.auto.
(e) $$profit$$!!
I agree that this looks like an effective solutio
d the
catalog so it represents all the details you want to preserve. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
er pragma synchronous=normal or synchronous=full should be the default, and
thankfully 'full' won.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew Dunstan wrote:
On 09/28/2010 09:31 PM, Darren Duncan wrote:
Code that quotes all of its identifiers, such as with:
FOR EACH "var" IN "array_expr" LOOP ...
This doesn't help in the least if the array is an expression rather than
simply a variable - we'
rsing should be easier, too, because keywords formatted like this would just
be a single term rather than having infinite variations due to embedded whitespace.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
ntifiers whatever is most suitably descriptive for them without
worrying whether the language has a pre-defined meaning for the used words.
The quoting also has the nice bonus of making them case-sensitive.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
Craig Ringer wrote:
On 25/09/2010 11:51 AM, Darren Duncan wrote:
There should just be a single syntax that works for all types, in the
general case, for testing whether a value is a member of that type, or
alternately whether a value can be cast to a particular type.
Pg already gets it right
aybe to test if a value can be cast as a type, you can continue the ::
mnemonic, say adding a "?" for yes and a "!" for no.
For example, "?::" tests if the value can be cast as the type
and "!::" or "not ?::" tests the opposite.
An expression li
ed at all by the delay in
migrating repositories while the CVS is cleaned up? -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ay to do object-relational databases, given that
pure functions and immutable data structures are typically the best way to
express anything one would do with them. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
variable. But
no worries; Heikki/Andrew/Alvaro understood what I meant.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
stand either "a0" or "rv" getting a
substitution, but something following an "AS" being substituted is just wrong.
Is that a bug and if not then what is the rationale for working that way, and
can it be changed?
Meanwhile, what is the best way to write f to work around th
Robert Haas wrote:
On Wed, Sep 15, 2010 at 2:32 PM, Darren Duncan wrote:
The point being, the answer to how to implement autonomous transactions
could be as simple as, do the same thing as how you manage multiple
concurrent client sessions, more or less. If each client gets its own
Postgres
1 - 100 of 110 matches
Mail list logo
