Hi,
I'll hope this is the correct list for these questions... :-/
I need to define several unique data types. As my "make one
to throw away" exercise, I rewrote the ISBN data type in
the contrib directory (hopefully bringing it "up to date"
as well as adding stricter checks in the parser and sh
Alban Hertroys wrote:
Ottavio Campana wrote:
CREATE TABLE person (
id SERIAL,
name TEXT
);
how can I do it with a INT8 instead of a INT4?
Do you really expect that sequence to reach over 2 billion? Otherwise
I'd stick with the SERIAL, nothing wrong with that unless you're
Martijn van Oosterhout wrote:
On Thu, Mar 30, 2006 at 11:51:41AM -0700, Don Y wrote:
[snipped questions and answers]
Thanks!
- Wish list item: errdetail(va_list arg) et al. functions (Yeah,
I can write my own... but it would be nice if this was part
of the error reporting routines
Tom Lane wrote:
Martijn van Oosterhout writes:
On Thu, Mar 30, 2006 at 11:51:41AM -0700, Don Y wrote:
- Can *_in() be ever invoked with a NULL argument? Or, can I
safely assume that the pointer I am passed is valid?
You can't get a NULL there. Yes, the pointer is valid cstring.
Tom Lane wrote:
Don Y <[EMAIL PROTECTED]> writes:
Yeah, I was hoping someone would have built a template for
new types that trimmed everything down to a single page/file
instead of having to snoop the source tree. :-(
The various new types in contrib/ are there in part to serve as
Hi,
I wasn't prepared to ask this question, yet :< but
all the talk of stored procedures, etc. suggests
this might be a good time to venture forth...
Humor me: assume I have done the analysis and *know*
this to be correct for my situation :>
I want to embed a good deal of the invariant aspec
Bernhard Weisshuhn wrote:
Don Y wrote:
[snip]
For example, the title may match an existing entry -- but
the author may be different (e.g., misspelled, or some
"other" author listed on a book having multiple authors, etc.).
Ideally, I would like the database to suspend the INSER
Hi,
Is there any way that I can consistently (across all
tables) add a parameter defining "what" each column
"is"? (sorry, crappy grammar and ill-formed question).
I want to be able to embed in the database parameters
that tell it how to interpret each column. In other
words, while the TYPE fo
What is the preferred way of issuing errors of the form:
"Delimiter expected after character #3"
(where "3" obviously varies).
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Hi,
I have a set of functions for a data type that return
small integers (i.e. [0..12]). I can, of course, represent
it as a char, short or long (CHAR, INT16 or INT32).
re there any advantages/drawbacks to chosing one particular
PG_RETURN_ type over another (realizing that they are
effectively j
Hi,
I've successfully built several user types. But, I'm having
problems with the one I am working on currently. The server
SIGSEGV's at the end of the _in routine.
Nearest I can tell, the problem is related to my attempt to
return an int "by value" (all of my other types return
references but
Richard Huxton wrote:
Don Y wrote:
Hi,
I have a set of functions for a data type that return
small integers (i.e. [0..12]). I can, of course, represent
it as a char, short or long (CHAR, INT16 or INT32).
re there any advantages/drawbacks to chosing one particular
PG_RETURN_ type over another
Martijn van Oosterhout wrote:
On Tue, May 02, 2006 at 08:43:03AM -0700, Don Y wrote:
Richard Huxton wrote:
Don Y wrote:
Hi,
I have a set of functions for a data type that return
small integers (i.e. [0..12]). I can, of course, represent
it as a char, short or long (CHAR, INT16 or INT32).
re
Martijn van Oosterhout wrote:
On Tue, May 02, 2006 at 10:06:19AM -0700, Don Y wrote:
The type as declared determines the storage required to store it. That
Yes, but for a function returning a value that does not exceed
sizeof(Datum), there is no *space* consequence. I would assume
most modern
Tom Lane wrote:
Don Y <[EMAIL PROTECTED]> writes:
Nearest I can tell, the problem is related to my attempt to
return an int "by value"
If that's what you intend, try cluing in CREATE TYPE (see
PASSEDBYVALUE).
Thanks! That did the trick!
--don
---
Hi,
If I define:
Datum barcode_checksum(PG_FUNCTION_ARGS)
PG_FUNCTION_INFO_V1(barcode_checksum)
Datum barcode_checksum(PG_FUNCTION_ARGS)
{
barcode value;
short result;
label = (barcode) PG_GETARG_INT32(0);
// compute barcode
PG_RETURN_INT16(result);
}
and now want to *use* that f
Martijn van Oosterhout wrote:
On Tue, May 02, 2006 at 11:24:34AM -0700, Don Y wrote:
Hi,
If I define:
Datum barcode_checksum(PG_FUNCTION_ARGS)
PG_FUNCTION_INFO_V1(barcode_checksum)
and now want to *use* that function within some other
(related) function, how can I invoke it? The
Hi,
Is there any way of mimicking the IS STRICT behavior
*without* declaring the function as "STRICT"?
E.g., I could use PG_ARGISNULL() to check for invocation
with a NULL argument. But, the function has already been
invoked at that point. I.e. I still have to *return*
something -- which might
Tom Lane wrote:
Don Y <[EMAIL PROTECTED]> writes:
Is there any way of mimicking the IS STRICT behavior
*without* declaring the function as "STRICT"?
Are you looking for PG_RETURN_NULL()? If not, this seems a bit
nonsensical.
No.
First, if the function is defined to retur
Martijn van Oosterhout wrote:
On Wed, May 03, 2006 at 11:02:26PM -0700, Don Y wrote:
(sigh) Sorry to be picking nits. I'm just trying to
sort out how to protect against folks making careless
mistakes in the future (e.g., forgetting STRICT in
the function declarations when adding a functi
Tom Lane wrote:
Don Y <[EMAIL PROTECTED]> writes:
Is there any way to prevent them from *adding* these functions
(i.e. build them into template) so they have to use them the
way *I* have already defined them?
Only if you think you can deny your users superuser privileges on
the
Martijn van Oosterhout wrote:
On Wed, May 03, 2006 at 11:45:31PM -0700, Don Y wrote:
Martijn van Oosterhout wrote:
Unfortunatly there is no way to ensure the user declares the function
in SQL in the way your code expects. I remember a discussion once about
allowing you to declare the essential
Tom Lane wrote:
Don Y <[EMAIL PROTECTED]> writes:
First, if the function is defined to return an INT16,
then returning a NULL doesn't make any sense -- since the
caller doesn't know how to deal with a NULL (it expects
an INT16, for example).
Really? That would be a cal
Martijn van Oosterhout wrote:
On Thu, May 04, 2006 at 12:19:12AM -0700, Don Y wrote:
I'm not designing for the "traditional" role that you're
used to so I can do whatever makes sense for this product
and just *define* that as it's behavior. Since there are
no other p
Martijn van Oosterhout wrote:
On Thu, May 04, 2006 at 12:29:30AM -0700, Don Y wrote:
OTOH, if the function could *abort* it's invocation, then
I don't have to worry about return values. It is a closer
model to the STRICT behavior -- instead of aborting the
function invocation BEF
Martijn van Oosterhout wrote:
On Thu, May 04, 2006 at 12:23:07AM -0700, Don Y wrote:
I don't want to hide the function; just ensure that no one
*redefines* the SQL interface to it in a manner that is
inconsistent with its implementation. If I can make the
implementation robust enough th
Hi,
I'm writing a set of casts to/from various user defined
types. As is unexpected, there are cases where one
data type doesn't neatly map to another (for certain
values). In these cases I emit an INVALID_PARAMETER_VALUE
or OUT_OF_RANGE error -- depending on the situation.
But, should I also
Given a user defined type foo...
I've created several casts to/from foo and built-in types.
I had adopted a naming convention of:
baz foo_to_baz(foo);
foo foo_from_baz(baz);
But:
...it is recommended that you continue to follow this old
convention of naming cast implementation functions
Tom Lane wrote:
Don Y <[EMAIL PROTECTED]> writes:
I'm writing a set of casts to/from various user defined
types. As is unexpected, there are cases where one
data type doesn't neatly map to another (for certain
values). In these cases I emit an INVALID_PARAMETER_VALUE
or OU
Martijn van Oosterhout wrote:
On Tue, May 16, 2006 at 10:29:27AM -0700, Don Y wrote:
Given a user defined type foo...
I've created several casts to/from foo and built-in types.
I had adopted a naming convention of:
baz foo_to_baz(foo);
foo foo_from_baz(baz);
But:
I don't see
Hi,
I have several user defined types with particular restraints
upon the data they represent. If I have crafted my foo_in()
function to ensure that these constraints are always satisfied
*before* allowing a datum into the database AND I have designed
my casts to be similarly vigilant, is there
Hi,
Is it possible to have one of my user defined data types
reviewed/critiqued to see if there are things that I am
not doing properly? Or, other things that I should be
including? Or, should I just contribute it and hope
for the best? (if so, how do I do that?)
Thanks!
--don
--
Martijn van Oosterhout wrote:
On Tue, May 16, 2006 at 08:12:05PM -0700, Don Y wrote:
Hi,
Is it possible to have one of my user defined data types
reviewed/critiqued to see if there are things that I am
not doing properly? Or, other things that I should be
including? Or, should I just
Hi,
It doesn't appear that there is a way to rename a sequence
(ideally with a "cascade" action).
Nor does there appear to be a way to change the owner of
a sequence.
Obviously, I can DROP and recreate... *but*, how prudent
(foolish?) would it be just to change the entries in the
system tables
Bruce Momjian wrote:
Don Y wrote:
Hi,
It doesn't appear that there is a way to rename a sequence
(ideally with a "cascade" action).
Uh, the ALTER SEQUENCE manual page says:
Uh, the 8.0.3 man page for ALTER SEQUENCE makes no mention of this.
Nor does "\h ALTER SEQUENC
Bruce Momjian wrote:
Don Y wrote:
Bruce Momjian wrote:
Don Y wrote:
Hi,
It doesn't appear that there is a way to rename a sequence
(ideally with a "cascade" action).
Uh, the ALTER SEQUENCE manual page says:
Uh, the 8.0.3 man page for ALTER SEQUENCE makes no mention of thi
Jim C. Nasby wrote:
On Wed, May 17, 2006 at 03:00:48PM -0700, Don Y wrote:
I see the documentation mention added August 1, 2005 byt Tom Lane.
Date tag on the bottom of my man pages is "2005-01-17" -- so that
explains *that*! :>
This is a very minor reason why you should be run
Tom Lane wrote:
Tim Allen <[EMAIL PROTECTED]> writes:
Don Y wrote:
So, I'll deploy them and get feedback on which features I
may need to add (some of the data types are probably a bit
too exotic for most users). I figure I can always contribute
them just before a release...
Ju
Tom Lane wrote:
Don Y <[EMAIL PROTECTED]> writes:
Jim C. Nasby wrote:
This is a very minor reason why you should be running the most recent
8.0.x release and not 8.0.3. A much bigger reason is that there are
data-loss bugs that have been fixed.
The folks watching the Postgres re
39 matches
Mail list logo
