Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

encoding/csv: add column level introspection capabilities #22590

Open
silviucm opened this issue Nov 5, 2017 · 2 comments
Open

encoding/csv: add column level introspection capabilities #22590

silviucm opened this issue Nov 5, 2017 · 2 comments
Labels
FeatureRequest NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone

Comments

@silviucm
Copy link

silviucm commented Nov 5, 2017

As briefly mentioned inside certain csv.Writer comments, there are frequent use cases, particularly with Postgres bulk copy to / from, where it is useful to differentiate between unquoted and quoted empty strings.

In particular, for csv.Reader, by the time Read() returns a slice of strings, it is too late to know whether a certain empty string is a quoted empty string or an unquoted one.

My particular use case deals with determining the nullability of an empty unquoted string, but - more generally - I just wanted to see if there is any appetite towards adding such column level introspection capabilities to the standard library csv.Reader and csv.Writer, without breaking compatibility.

For Reader, this would expose an additional surface perhaps similar to:

  type CsvValue interface {
	Quoted() bool 	// returns true if the value is quoted, false otherwise
	String() string
	// ... whatever else comes to mind
   }

   func (r *Reader) ReadValues() (record []CsvValue, err error) {
		...
   }

Regards,
silviu

@ianlancetaylor
Copy link
Contributor

I think there is very little appetite for adding any new API to encoding/csv.

@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Nov 7, 2017
@ALTree ALTree added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Mar 3, 2019
@sandan
Copy link

sandan commented Mar 5, 2020

The problem seems to be differentiating between a NULL value vs. an empty string for string database types. RFC4180 doesn't seem to have any rules regarding this. How about this proposal instead:

  1. Any fields that have quoted empty strings in a record will be considered empty strings when read in csv.Reader. For example the record:
    a,"",b returns ["a", "", "b"]

  2. Any fields that are unquoted empty strings in a record will be considered nil when read in csv.Reader. For example, the record:
    a,,b returns ["a", nil, "b"]

And vice versa for csv.Writer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FeatureRequest NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Development

No branches or pull requests

4 participants